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ABSTRACT 


Modem  Modeling  and  Simulation  (M&S)  techniques  offer  flexible,  economical 
capabilities  for  assessing  naval  installation  security  systems,  equipment  and  Concepts  of 
Operations  (CONOPS).  These  tools  are  useful  for  assessing  risk  and  vulnerability  in  a  broad 
range  of  operational  situations  and  in  response  to  a  spectrum  of  threat  scenarios.  Of  particular 
interest  to  both  military  and  homeland-defense  analysts  is  the  combined  shore-side  and  water¬ 
side  protection  of  naval  and  harbor  facilities. 

In  August  of  2005,  the  NPS  MOVES  Institute  was  funded  by  the  Naval  Facilities 
Engineering  Service  Center  (NFESC)  to  investigate  and  develop  such  an  analytic  tool.  This 
report  describes  the  work  accomplished  during  Phase  II  of  the  Modeling  and  3D  Visualization 
for  Evaluation  of  Anti-Terrorism/Force  Protection  Alternatives  project  in  order  to  achieve  that 
goal. 

Waterside  protection  includes  surveillance  (detection  and  assessment),  delay  (e.g., 
barriers),  and  warning  and  response  means  (e.g.,  patrol  craft).  The  purpose  of  the  Phase  II  effort 
was  to  develop  an  analysis  tool  that  supports  assessment  of  the  effectiveness  of  various  sensor, 
barrier,  and  response  systems  to  enable  decision-makers  to  make  good  judgments  on  what  to 
purchase  and  employ.  For  example,  if  there  is  no  physical  barrier  in  a  port  to  protect  naval  assets 
then  when  does  a  threat  need  to  be  detected  to  permit  sufficient  time  to  intercept/neutralize  and 
how  many  patrol  craft  and/or  weapon  stations  are  needed  to  provide  an  acceptable  level  of 
protection?  Alternatively,  if  a  barrier  is  employed  that  effectively  stops  all  small  boats  for  a 
designated  period  of  time,  then  when  does  detection  need  to  occur  and  how  many  patrol  boats 
are  needed  for  the  same  level  of  protection?  With  various  surveillance  system  assets  (including 
surface  and/or  subsurface  sensors),  how  much  time  is  available  between  detection/reporting  and 
response? 

The  selection  of  effective  combinations  of  sensors,  barriers,  and  response  systems 
requires  a  tool  that  can  represent  all  these  various  assets  and  physical  factors,  providing  insights 
into  the  most  effective  combinations  that  provide  an  acceptable  level  of  protection  at  the  least 
cost  (in  terms  of  manpower  and  dollars)  and  least  risk  (in  terms  of  lives  and  infrastructure). 
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1.0  INTRODUCTION 


Modeling  and  Simulation  (M&S)  techniques  offer  flexible,  economical  capabilities  for 
assessing  naval  installation  security  systems,  equipment  and  Concepts  of  Operations  (CONOPS). 
These  tools  are  useful  for  assessing  risk  and  vulnerability  in  a  broad  range  of  operational 
situations  and  in  response  to  a  spectrum  of  threat  scenarios.  Of  particular  interest  to  both 
military  and  homeland-defense  analysts  is  the  combined  shore-side  and  water-side  protection  of 
naval  and  harbor  facilities. 

1.1  BACKGROUND 

The  primary  products  for  this  phase  of  work  are  the  Sullivan  thesis,  the  Rauch  Thesis,  the 
M&S  Workshop  and  the  software  and  models  distributions.  This  report  provides  additional 
amplifying  information. 

The  Systems  Engineering  tasks  associated  with  the  naval  installation  security  span  the 
breadth  of  Navy  CONUS  and  OCONUS  bases.  They  must  cover  many  existing  “legacy”  and 
proposed  new  systems.  The  Systems  Engineering  effort  includes  analysis,  trades,  and 
requirements  definition  and  refinement.  The  outputs  will  provide  the  basis  for  recommendations 
for  procurement,  training  methods,  concepts  of  operation  -  in  other  words,  all  standard  outputs 
from  the  Systems  Engineering  process  for  systems  that  are  to  meet  the  operational  needs  of  the 
naval  installation  security  initiative. 

The  challenges  facing  the  naval  installation  security  problem  are  complicated  by  the 
widely  varying  nature  of  the  threats  to  be  addressed,  by  the  diversity  of  existing  systems, 
equipment  and  Concept  of  Operations  (CONOPS),  and  by  the  fact  that  there  are  more  than  100 
U.S.  naval  facilities,  each  of  which  can  be  expected  to  have  a  different  set  of  Anti- 
Terrorism/Force  Protection  (AT/FP)  requirements  and  solutions  for  harbor  defense  and 
installation  security.  As  a  result,  it  is  simply  not  practical  to  conduct  these  analyses  on  a  purely 
empirical  basis  by  installing  and  trying  different  combinations  of  equipment  and  systems.  A 
better,  more  cost-effective  approach  for  Systems  Engineering  analysis  is  needed  (sponsor  sets  the 
requirements). 

A  widely  accepted  methodology  for  dealing  with  complex  systems  is  the  use  of  M&S. 
M&S  tools  allow  a  user  -  from  the  analyst  to  the  civilian  administrator  to  the  military  operator  - 
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to  assemble  simplified  representations  of  actual  systems  that  allow  an  understanding  of 
underlying  relationships  among  sensors,  combatants  and  their  behaviors,  all  against  the  backdrop 
of  3D,  immersive  displays  of  actual  locations  such  as  a  harbor  and  surrounding  areas. 

The  abstract  from  (Harney  2003)  describes  the  genesis  of  this  project: 

Despite  the  many  advances  achieved  within  both  Modeling  and  Simulation  and 
Information  Technology  over  the  past  several  decades,  practical  application  of 
such  technology  remains  under-utilized  by  operational  units  in  the  United  States 
Navy.  Furthermore,  when  such  technology  has  been  deployed  in  the  last  decade  it 
has  been  to  exercise  operator  proficiency  or  increase  C4I  battlespace  awareness. 

Few  tools  have  allowed  operational  warfighters  to  run  ‘what-if  simulation 
scenarios  to  aid  in  development  of  tactical  plans  for  executing  published  doctrine. 

The  approach  taken  in  this  thesis  is  to  select  an  exemplar  warfare  area,  in  this  case 
Anti-Terrorism  and  Force  Protection  for  Navy  ships,  and  through  research  and 
development  to  identify,  develop,  and  deploy  the  necessary  modeling  and 
simulation  (M  &  S)  technologies  to  demonstrate  a  prototypical  planning  tool  that 
can  be  used  by  today’s  deployed  warfighter.  All  research  and  work  is  conducted 
in  a  web-based,  ‘user-centric’  fashion  utilizing  a  combination  of  user-driven  and 
agent-based  control  of  entities  for  simulation  iterations,  along  with  various  open 
source  technologies  which  include  Extensible  3D  Graphics  (X3D),  Scalable 
Vector  Graphics  (SVG),  and  Extensible  Markup  Language  (XML).  Conventions 
are  demonstrated  for  the  integration  of  the  many  academic  disciplines  utilized 
during  this  research  to  achieve  automatic  generation  of  tactically  significant 
scenarios.  In  order  to  give  the  end-user  the  greatest  insight  towards  potential 
drawbacks  in  the  tactical  planning  against  surface-borne  terrorist  threats,  various 
2D  and  3D  media  provide  both  real-time  and  non-real  time  scenario  playback. 

The  result  of  this  work  is  a  fully  integrated,  prototypical,  Java-based  application 
that  demonstrates  how  various  Open-Source,  web-based  technologies  can  be 
applied  in  order  to  provide  the  tactical  operator  with  tools  to  aid  in  Force 
Protection  planning.  Scenarios  can  be  auto  generated,  viewed,  analyzed,  and 
manipulated  by  end  users  with  little  to  no  computer  experience  necessary  beyond 
requirements  for  operation  of  a  desktop  personal  computer  (PC)  in  the 
Information  Technology  for  the  21st  Century  (IT-21)  environment  at  sea.  This 
approach  has  broad  applicability  to  improve  the  tactical  awareness  and  defensive 
posture  of  ships  defending  against  terrorist  attacks  in  port. 
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1.2  PROJECT  OBJECTIVES 

The  primary  intended  outcome  of  the  project  is  to: 

•  Communicate  general  goals  for  improving  naval  installation  security  through  M&S 

•  Define  potential  goals  for  M&S  programs  that  support  implementation  of  naval 
installation  security  systems 

•  Discuss  candidate  M&S  requirements  for  naval  installation  security  studies  and 
analyses 

•  Describe  and  demonstrate  relevant  M&S  capabilities  and  approaches 

•  Assess  the  state-of-the-art  in  M&S  as  related  to  naval  installation  security 

•  Identify  potential  areas  for  data  interchange  and  collaboration  through  data  and  model 
sharing 

•  Identify  the  most  productive  areas  for  further  M&S  development 

•  Explore  how  to  create  broader-based  tool  support  for  tactical  analysis  of  harbor  risk 
and  vulnerabilities. 

1.2.1  Phase  I  Project  Objectives 

During  the  Phase  I  effort,  the  decision  was  made  to  integrate  the  extended  capabilities  for 
a  AT/FP  Visualization  and  Analysis  Tool  into  a  different  established  code  base,  the  Autonomous 
Unmanned  Vehicle  (AUV)  Workbench  (AUVW).  This  tool  provides  2D  and  3D  mission 
planning  and  mission  execution  with  integrated  vehicle  dynamics  and  basic  sensor  physics.  The 
current  open  source  code  base  provides  a  more  extensive  framework  for  addition  of  capabilities 
and  features  to  meet  requirements  of  the  AT/FP  analysis  tool. 


1.2.2  Phase  I  Project  Accomplishments 

Accomplishments  from  the  Phase  I  effort  conducted  through  the  first  two  quarters  of 
fiscal  year  2005  set  the  foundation  for  continuing  work.  This  work  included: 

•  3D  modeling  of  NAVMAG  Indian  Island,  Washington,  including  development  of 
Ammunition  Pier,  nearby  buildings,  and  surrounding  terrain 
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•  3D  modeling  and  texture  mapping  of  NAVSTA  Bremerton,  Washington,  including 
development  of  piers,  near  shore  buildings,  and  surrounding  terrain 

•  3D  modeling  of  port  security  barriers  and  a  selection  of  water  craft 

•  Further  development  of  existing  software  infrastructure  in  Xj3D,  including  initial 
efforts  to  integrate  the  open-source  Open  Dynamics  Engine  (ODE)  software  library 

•  Gathering  geospatial  information  sets  for  multiple  locales 

•  Gathering  technical  information  for  barriers  and  sensors 

•  User  interface  design  for  the  overall  planning  and  assessment  tool 

•  Establishing  working  relationships  and  coordination  mechanisms  across  the  project 
team  (NFESC,  Sound&Sea  Technologies,  NPS,  Planet  9,  and  Yumetech) 


1.2.3  Phase  II  Project  Objectives 

Waterside  protection  includes  surveillance  (detection  and  assessment),  delay  (e.g., 
barriers),  and  warning  and  response  means  (e.g.,  patrol  craft).  The  purpose  of  the  proposed 
effort  is  to  develop  an  analysis  tool  that  supports  assessment  of  the  effectiveness  of  various 
sensor,  barrier,  and  response  systems  to  enable  decision-makers  to  make  good  judgments  on 
what  to  purchase  and  employ.  For  example,  if  there  is  no  physical  barrier  in  a  port  to  protect 
naval  assets  then  when  does  a  threat  need  to  be  detected  to  permit  sufficient  time  to 
intercept/neutralize  and  how  many  patrol  craft  and/or  weapon  stations  are  needed  to  provide  an 
acceptable  level  of  protection?  Alternatively,  if  a  barrier  is  employed  that  effectively  stops  all 
small  boats  for  a  designated  period  of  time,  then  when  does  detection  need  to  occur  and  how 
many  patrol  boats  are  needed  for  the  same  level  of  protection?  With  various  surveillance  system 
assets  (including  surface  and/or  subsurface  sensors),  how  much  time  is  available  between 
detection/reporting  and  response?  The  selection  of  effective  combinations  of  sensors,  barriers, 
and  response  systems  requires  a  tool  that  can  represent  all  these  various  assets  and  physical 
factors,  providing  insights  into  the  most  effective  combinations  that  provide  an  acceptable  level 
of  protection  at  the  least  cost  (in  terms  of  manpower  and  dollars)  and  least  risk  (in  terms  of  lives 
and  infrastructure). 
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1.2.4  Phase  II  Project  Accomplishments 


Allocation  of  AT/FP  Visualization  and  Analysis  Tool  SOW  Tasks  to  Performers 

SOW 

Para 

Task 

NPS 

Planet  9 

Yumetech 

Aniviza 

Daly 

Realism 

Sonalysts 

Media 

Machines 

Okino 

4.1 

Port  and  Port 

Facility  Modeling 

4.1.1 

Indian  Island  and 
Bremerton 

Visualization 

Improvements 

X 

PRIME 

X 

X 

4.1.2 

Pearl  Harbor  and  Port 
Hueneme 

Visualizations 

X 

PRIME 

X 

X 

4.1.3 

Assess  Shore-Side 
integration 

PRIME 

4.1.4 

Physics-based 

models 

PRIME 

X 

X 

X 

4. 1.4.1 

Sonar  modeling 

PRIME 

X 

4.1.5 

DNC  load/display 

X 

PRIME 

X 

4.1.6 

Navy  C2  in  tool 
modeling 

PRIME 

4.1.7 

X3D  Tool  Updates 

X 

PRIME(I) 

PRIME(2) 

4.2 

Analysis  Tool 
Development 

4.2.1 

Integration  with 

AUVW 

PRIME 

X 

X 

X 

X 

GUI  for  scenario  set¬ 
up 

X 

PRIME 

X 

X 

Simkit  scenario 
creation 

X 

PRIME 

X 

Experimental  design 
tool 

X 

PRIME 

X 

Analysis  report¬ 
writing 

PRIME 

Web3D  2D/3D  Ul 
Working  Group 

X 

X 

PRIME 

X 

X 

4.2.7 

NMCI/IT-21 

PRIME 

X 

X 

4.2.8 

Configuration  control 

PRIME 

X 

X 

X 

X 

4.2.9 

Remainder  FY05 
activities 

X 

X 

X 

X 

4.2.10 

Computing  Cluster 

PRIME 

KB 

Education  and 
Training 

Instructional  materials 

X 

PRIME 

X 

Conduct  training 

PRIME 

X 

Documentation 

X 

X 

X 

X 

PRIME 

■ 

Team  coordination 
and  management 

PRIME 

X 

X 

X 

X 

X 

X 

X 

Record  follow-on 
requirements 

PRIME 

X 

X 

X 

X 

NOTE:  "PRIME"  means  primary  responsibility  for  execution  of  the  task. 
(1)  VizX3D  product  update;  (2)  Polytrans  product  update 


Table  1.  List  of  Phase  II  Accomplishments  by  Partners  (From  Phase  II  SOW  2006) 
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SAVAGE  Mission  Analysis 
Language  (SMAL) 

Terse  XML 
Describe  assets 
and  positions  in 
the  tactical 
scenario 


2D 


2D  Scenario  Display 


2D  Authoring  &  Annotation 


Swing 

Panels 


3D 


.x3d  scene 

SAVAGE  Vehicle  Prototypes 
SAVAGE  Model  Archives 
X3D  Bathymetry 
Barrier  Prototypes 
Screen  Snapshots 
Collision  Sensors  /  Physics 


Alan  Hudaon 
Chnttian  Oevd 

SAVAGE  Taaro 


Optional  human  control  : 
of  individual  entity 


VisKit  Scenario 
for  all 
Entities 

Simpis  ReuutM  Pnyiics 


Design  of 
Experiments  Panel 


Report  View  & 
Analyst  Annotation 


Traffic  Analysis 
Module 


Rich,  Goldberg 
Don  McGregor 
Amle  Bum 
Mke  Biloy 


Simkit 

Event  Graphs  & 
Assemblies 


Scenario 

Run 

(Real-Tm«) 


AVCL  Mosico  Record 
to  each  entity 


Cluster  & 
Dispatcher 
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Zh 


Annotated 
Analysis  Report 


Integrated  GUI  Components 


Open  Map  GIS  Overlays 


Entity  Tactical  Configuration 


Pick  &  Place  Icons 


Barrier  Definition 


AVCL  Mission  Overlay 


Shoreline  Annotation 

(M>o  xnt  to  VttKit  border  doss) 


Entity  Animation 


A 


.smal 


Waterside  Security 
Analysis  Report 

Scenario  Description 
Mission  Description 
Statistical  Effectiveness 
Analyst  Conclusions 
References 

Cost  I  Benefit  I  Risk  Analysis 


Analysis 

Report 

Archive 


Aggregated 
Configuration  Files 


Figure  1.  Overall  Software  Architecture  for  the  Anti-Terrorism/Force  Protection  (AT/FP) 

Analysis  Tool  (From  Phase  II  SOW  2006) 
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Figure  2.  POA&M  for  Phase  II  Efforts  (Part  I)  (From  Phase  II  SOW  2006) 
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Figure  3.  POA&M  for  Phase  II  Efforts  (Part  II)  (From  Phase  II  SOW  2006) 
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1.3  PROJECT  MANAGEMENT  ORGANIZATION 

1.3.1  Naval  Postgraduate  School  (NPS) 

Donald  P.  Brutzman,  Ph.D.,  NPS  Principal  Investigator  (PI) 

Arnold  Buss,  Ph.D.,  Simkit  Software  Engineer 
Mike  Bailey,  Viskit  Software  Engineer 

Don  McGregor,  High  Performance  Computing  (HPC)  Cluster  Engineer 

Jeff  Weekley,  3D  Modeler 

LCDR  Travis  Rauch,  USN,  Thesis  Researcher 

LT  Patrick  Sullivan,  USN,  Thesis  Researcher 

Curt  Blais,  Project  Support,  Final  Report  Editor 

Terry  Norbraten,  Project  Support,  Final  Report  Editor 

1.3.2  Naval  Facilities  Engineering  Service  Center  (NFESC) 

Mr.  Robert  Taylor 

Alexandria  De  Visser 

1.3.3  Sound  and  Sea  Technologies  (S&ST) 

Dallas  Meggit 

Dennis  Garrood 
Mario  Pozzo 
Roger  Christiansen 
Denise  Bjorling 
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1.3.4  Yumetech,  Inc. 

Alan  Hudson,  CEO 

Justin  Couch 
Stephen  Matsuba 


1.3.5  Aniviza,  Inc. 

Rick  Goldberg,  CEO 


1.3.6  Planet  9  Studios 

David  Colleen,  CEO 

Chris  Greuel,  3D  Model  Engineer 
Dan  Ancona,  Documentation  and  Training 
Carlos  Newcomb,  3D  Imagery 


1.3.7  Media  Machines 

Tony  Parisi,  CEO 

Keith  Victor,  Software  Engineer 


1.3.8  Okino  Computer  Graphics,  Inc. 

Robert  Landsdale,  CEO 

Andrew  Grieve 


1.3.9  Daly  Realism 

Leonard  Daly,  CEO,  Software  Documentation 


10 


1.3.10  Sonalysts 

Margaret  Bailey 

Doug  Nelson,  Physics  Modeling 


1.4  ORGANIZATION  OF  THIS  REPORT 

Chapter  1  is  the  introduction  of  this  report  and  covers  the  overview  and  objectives  of 
Phase  II  efforts.  Chapter  2  covers  the  objectives  and  requirements  of  the  May  2006  M&S 
Workshop.  Chapter  3  highlights  two  thesis  abstracts  and  the  Phase  II  partner  contributions  and 
final  reports  submitted  by  each.  Chapter  4  covers  the  summary  and  conclusions  of  this  final 
report.  Appendix  A  lists  the  attendees  and  the  agenda  of  the  May  2006  M&S  Workshop. 
Appendix  B  lists  the  MOVES  Open  House  2006  tutorial  agenda  for  the  AT/FP  Analysis  Tool. 
Appendix  C  contains  the  AT/FP  Project  Flyer.  Appendix  D  contains  information  on  how  to 
obtain  a  copy  of  the  FOUO  May  2006  M&S  Workshop.  Appendix  E  contains  a  white  paper 
covering  Diskit  Sensor  and  Mover  dynamics  by  Rick  Goldberg,  Aniviza,  Inc.  Appendix  F 
contains  Planet  9  slidesets  detailing  3D  model  construction  techniques.  Appendix  G  concludes 
this  report  with  a  technical  summary  of  Phase  II  efforts  from  Planet  9  Studios. 
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2.0  NAVAL  INSTALLATION  SECURITY  MODELING  &  SIMULATION 


2.1  NAVAL  INSTALLATION  SECURITY  M&S  OBJECTIVES 

Broadly  stated,  the  objectives  of  naval  installation  security  M&S  are  to: 

•  Develop  open-source/open  standards  (nonproprietary)  modeling  and  simulation  tools 
to  evaluate  contributions  of  system  and  equipment  alternatives  to  Naval  and  U.S. 
Coast  Guard  installation  security  effectiveness.  This  is  envisioned  to  include  a  series 
of  tools  of  differing  complexity  and  fidelity  for  different  applications. 

•  Develop  and  evaluate  concepts  of  layered  defense  using  existing,  emerging  and 
potential  future  physical  security  and  Command,  Control,  Communications, 
Computers  and  Intelligence  (C4I)  systems  and  equipment. 

•  Facilitate  the  evaluation  of  equipment  and  systems  in  the  models  by  providing  an 
industry  standard  (e.g.,  Microsoft  EXCEL®)  interface  for  outputting  simulation 
initial  conditions  and  results.  This  interface  will  provide  the  user  an  efficient  and 
tailored  way  of  reporting  and  displaying  the  data  and  will  facilitate  the  use  of  data 
post-processors  for  the  generation  of  user-defined  Measures  of  Performance  (MOPs) 
and  Measures  of  Effectiveness  (MOEs). 

2.2  NAVAL  INSTALLATION  SECURITY  M&S  REQUIREMENTS 

A  preliminary  set  of  M&S  requirements  to  meet  the  objectives  listed  above  include: 

•  Perform  physically-based  statistical  assessment  and  visualization  to  evaluate  the 
effectiveness  of  sensors,  barriers,  and  response  systems  for  naval  installation 
security. 

•  Be  a  true  tool  set  (i.e.,  not  a  site-specific  simulation),  structured  so  the  users  can 
select  model  fidelity  and  scale  into  a  simulation  that  provides  a  realistic  solution  to 
their  particular  problem. 

•  Provide  realistic,  extensible,  3D  visualization  models  of  bases  and  surrounding 
environment,  including  bodies  of  water,  together  with  high-fidelity,  physics-based 
sensor,  dynamics  and  damage  assessment  models. 
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•  Include  the  capability  for  the  design  of  problems  and  scenarios  and  implementation 
of  these  problems  on  clusters  of  computers  or  a  dedicated  DoD  supercomputing 
facility. 

•  Support  training  in  a  dynamic,  realistic  environment  for  boat  handling,  weapons, 
tactical  control,  and  all  other  areas  of  waterside  and  shoreside  security  and  response. 

•  Allow  quantitative  evaluation  of  the  performance  of  sensors  and  systems  of  sensors 
through  “hardware-in-the-loop”  simulations. 

•  Support  the  conduct  of  pre-mission  planning/post  mission  analysis. 

•  Provide  quick  results  to  common  naval  installation  security  problems  through  the 
use  of  a  library  of  pre- worked  simulations. 

•  Provide  tools  to  allow  easy  generation  of  a  notional  harbor  (in  3D),  suitable  objects 
and  behaviors  for  training  and  demonstration  purposes. 

•  Implement  the  M&S  tools  in  an  open-source  software  environment  to  eliminate 
dependence  on  proprietary  software,  or  a  single  or  limited  number  of  vendors,  and  to 
eliminate  recursive  DoD  costs  for  such  software. 

•  Provide  interfaces  to  internal  calculated  results  and  external  programs  such  as 
MathWorks’  MATLAB®  and  Microsoft  EXCEL®  for  user  defined  report 
generation. 

2.3  AT/FP  ANALYSIS  TOOL  SOFTWARE  REQUIREMENTS 

AT/FP  Harbor  Security  Visualization  and  Analysis  Tool  Development  -  In  addition 
to  visualization  of  the  environment  to  aid  in  understanding  employment  of  security  resources,  an 
analysis  tool  is  needed  to  configure  and  run  experiments  to  evaluate  the  effectiveness  of  different 
combinations  of  AT/FP  assets  against  a  variety  of  threats.  Refer  to  Figure  1  for  an  overview  of 
the  major  software  components  of  this  tool.  The  NPS  team  will  perform  the  following  subtasks 
to  design,  develop,  test,  and  demonstrate  an  AT/FP  Harbor  Security  Visualization  and  Analysis 
Tool: 

Integration  with  AUVW:  Integrate  AT/FP  modeling  with  the  AUV  Workbench  code 
base  to  create  the  AT/FP  Harbor  Security  Visualization  and  Analysis  Tool. 
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GUI  for  Scenario  Set-up:  Design  and  begin  development  and  testing  of  a  user  interface 
to  facilitate  selection  of  a  locale  and  configuration  of  platforms,  sensors,  countermeasures, 
threats,  and  other  assets  involved  in  AT/FP  studies. 

Simkit  Scenario  Creation:  Design,  develop,  and  test  scenario  simulation  using  the 
Simkit  Discrete  Event  Simulation  (DES)  Application  Program  Interface  (API).  Simulation 
modeling  will  use  the  Viskit  visual  event  graph  tool  for  retention  and  reuse  of  modeling 
components. 

Experimental  Design  Tool:  Create  an  experimental  design  and  execution  harness  for 
conducting  analyses  using  the  AT/FP  Harbor  Security  Visualization  and  Analysis  Tool.  Utilize 
low-cost  computer  clusters  for  heavy-duty  computational  performance. 

Analysis  Report-writing:  Design  and  develop  an  analysis  report-writing  capability  to 
facilitate  preparation  of  reports  providing  analysis  results  from  the  tool.  Target  audiences 
include  AT/FP  acquisition  officers,  AT/FP  harbor  supervisors,  and  AT/FP  officers  on  ships 
entering  port. 

Web3D  2D/3D  UI  Working  Group:  Participate  in  the  2D/3D  User  Interface  (UI) 
Working  Group  in  the  Web3D  Consortium.  The  GUI  design  of  the  AT/FP  Harbor  Security 
Visualization  and  Analysis  Tool  is  critical  to  its  rapid  adoption  and  effective  employment.  This 
is  a  sophisticated  and  complicated  area  of  software  design;  however,  the  solution  in  the  tool 
development  will  be  evolving  as  problems  are  resolved.  Participation  in  this  group  will  ensure 
that  best-practice  design  patterns  are  utilized  and  combined  repeatably.  Web3D  Consortium 
membership  is  required  for  participation. 

NMCI  Port:  Identify  expected  user  operational  hardware/software  configurations  and 
determine  the  most  effective  means  for  deploying  (or  making  available)  the  software,  data,  and 
analytical  capabilities  into  those  environments  (e.g.,  NMCI  environment). 
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Configuration  Control:  Maintain  the  code  base  under  configuration  management  and 
prepare  software  installation  packages. 

Remainder  FY05  Activities:  For  FY2005,  complete  subtask  4.1.1  and  commence 
subtasks  4.1.2  plus  all  follow-on  subtasks. 

Computing  Cluster:  Obtain  and  configure  hardware  and  software  for  a  high 
performance  cluster  environment  to  support  rapid  execution  of  AT/FP  analyses. 
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3.0  PHASE  II  PARTNER  CONTRIBUTIONS 


3.1  INTRODUCTION 

This  effort  was  only  able  to  get  underway  with  the  contributions  of  each  and  every 
component/partner/researcher  assigned  to  this  project.  Listed  in  this  section  are  abstracts  from 
two  theses,  written  by  Naval  Officers  who  conducted  research  on  vital  pieces  of  this  project,  and 
the  Phase  II  final  reports  generated  from  work  performed  in  support  by  contributing  partners. 

3.2  NAVAL  POSTGRADUATE  SCHOOL 

3.2.1  LCDR  Travis  Rauch,  USN  Thesis 

Abstract  from  (Rauch  2006): 

Visualizing  operations  environments  in  three  dimensions  (3D)  supports  the 
warfighter’s  ability  to  make  rapid,  well-informed  decisions  by  presenting  complex 
systems  in  a  naturalistic,  integrated  display  format.  Unfortunately,  constructing 
these  environments  is  a  time-consuming  task  requiring  specific  expertise  not 
typically  available  in  the  command  center.  The  future  use  of  3D  visualization  in 
military  operations  depends  on  the  ability  of  personnel  with  minimal  graphics 
experience  to  create  virtual  environments  quickly  and  accurately  by  leveraging 
data-driven  customization  of  content  from  model  archives  with  the  data  available 
in  the  command  center.  Practical  3D  visualization  depends  on  standardized  scene 
autogeneration. 

The  Extensible  3D  (X3D)  Graphics  family  of  specifications  is  approved  by  the 
International  Standards  Organization  (ISO)  as  the  Web-based  format  for  the 
interchange  and  rendering  of  3D  scenes.  Previous  work  has  demonstrated  that  an 
archive  of  X3D  scenes,  such  as  the  Scenario  Authoring  and  Visualization  for 
Advanced  Graphical  Environments  (SAVAGE)  library,  can  be  used  to 
autogenerate  sophisticated  3D  tactical  environments.  Assembling  and  making 
sense  of  the  data  necessary  to  autogenerate  a  3D  environment  requires  context  and 
good  documentation,  best  accomplished  through  metadata.  Metadata  also  supports 
data-centric,  component-based  design;  key  philosophies  in  promoting 
interoperability  of  networked  applications.  Coupled  with  recent  developments  in 
X3D,  enhanced  features  of  the  Savage  X3D  Model  archives  are  now  sufficiently 
mature  to  support  rapid  generation  of  tactical  environments. 

This  thesis  proposes  an  XML  metadata  standard  to  collect  and  organize  the 
information  necessary  to  create  and  populate  a  tactical  3D  virtual  environment: 
the  Savage  Modeling  and  Analysis  Language  (SMAL).  The  logical  extension  of  a 
well  designed  standard  is  the  ability  to  cross  the  boundaries  of  usage,  allowing 
simulators  to  share  data  with  command  and  control  (C2)  suites  and  mission 
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planning  tools  based  on  the  construction  of  a  virtual  scene.  SMAL  provides  the 
informational  “glue”  necessary  to  perform  tactical  modeling,  simulation,  and 
analysis  using  networked,  physics-based  X3D  virtual  environments. 


3.2.2  LT  Pat  Sullivan,  USN  Thesis 

Abstract  from  (Sullivan  2006): 

The  individuals  charged  with  the  task  of  planning,  developing  and  implementing 
force  protection  measures  both  at  the  unit  and  installation  level  must  consider 
numerous  factors  in  formulating  the  best  defensive  posture.  Currently,  force 
protection  professionals  utilize  multiple  sources  of  information  regarding 
capabilities  of  systems  that  are  available,  and  combine  that  knowledge  with  the 
requirements  of  their  installation  to  create  an  overall  plan.  A  crucial  element 
missing  from  this  process  is  the  ability  to  determine,  prior  to  system  procurement, 
the  most  effective  combination  of  systems  and  employment  for  a  wide  range  of 
possible  terrorist  attack  scenarios. 

This  thesis  is  inspired  by  the  work  done  by  James  Harney,  LT,  USN:  “Analyzing 
Anti-Terrorist  Tactical  Effectiveness  of  Picket  Boats  for  Force  Protection  of  Navy 
Ships  Using  X3D  Graphics  and  Agent-Based  Simulation”  (Harney  2003).  The 
thesis  will  expand  the  Anti-Terrorism  Force  Protection  Tool  developed  during  the 
original  thesis  by  including  the  capability  of  testing  force  protection  measures  in 
multiple  scenarios  by  utilizing  models  of  force  protection  equipment  and  forces, 
virtual  worlds  of  existing  naval  facilities,  and  terrorist  agents  that  exhibit  intent 
and  behavioral  characteristics  which  can  test  the  effectiveness  of  the  force 
protection  equipment  used. 

The  result  of  this  work  is  a  scalable  and  repeatable  methodology  for  generating 
large-scale,  agent-based  simulations  for  AT/FP  problem  domains  providing  3D 
visualization,  report  generation,  and  statistical  analysis. 


3.3  SOUND  &  SEA  TECHNOLOGIES  (S&ST) 

3.3.1  Overview  of  S&ST  Contributions 

The  Naval  Facilities  Engineering  Service  Center  (NFESC)  is  responsible  for  planning 
and  executing  a  comprehensive  Anti-Terrorism/Force  Protection  (ATFP)  Ashore  program  to 
develop,  evaluate,  deploy  and  sustain  components,  subsystems  and  systems  to  reduce  the 
vulnerability  of  naval  facilities  and  assets  worldwide  to  attack  by  terrorists. 
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As  part  of  the  planning  tasks,  the  ATFP  Ashore  System  Engineering  analysts  must 
consider  many  existing  and  proposed  systems,  installed  in  a  multitude  of  different 
configurations,  at  in  excess  of  200  Naval  installations,  each  with  a  specific  set  of  requirements 
applied  over  a  wide  range  of  threat  scenarios.  The  tasks  include  analysis,  trade  studies  and 
requirements  definition,  with  the  objectives  of  providing  recommendations  for  system 
configurations  for  procurement,  measures  of  performance  (MOP),  and  assessment  of  the 
effectiveness  (MOE)  of  planned  and  installed  systems,  development  of  concepts  of  operation  and 
support  of  training  for  ATFP  response  forces. 

It  is  simply  not  practical  to  conduct  these  analyses  on  a  purely  empirical  basis,  by 
installing  and  trying  different  combinations  of  equipment  and  systems.  It  is  necessary  to  obtain 
site-specific  data  on  the  physical  conditions,  local  threats  and  resultant  vulnerabilities  of  each  site 
before  applying  either  material  or  non-material  solutions.  Flowever,  it  is  equally  obvious  that  it 
is  not  cost-effective  to  develop  a  set  of  material  options  and  methods  for  every  site  by  physical 
trial  and  error  alone.  A  better,  more  cost-effective  approach  for  Systems  Engineering  analysis  is 
required. 

A  widely  accepted  methodology  for  dealing  with  complex  systems  is  to  use  a  Modeling 
and  Simulation  (M&S)  approach.  M&S  tools  can  provide  a  tool  set  that  allows  the  user  -  from 
the  analyst  to  the  civilian  administrator  to  the  military  operator  -  to  assemble  simplified 
representations  of  an  actual  system  that  allows  an  understanding  of  underlying  relationships 
among  sensors,  combatants  and  their  behaviors,  all  against  the  backdrop  of  3D,  immersive 
displays  of  actual  locations  such  as  a  harbor  and  surrounding  areas. 

Sound  and  Sea  Technology  personnel  conducted  a  survey  (Garrood  2006)  of  available 
M&S  software  within  the  DoD  community  and  prepared  a  companion  white  paper  (Garrood,  et 
al  2006)  on  the  results.  These  papers  are  available  as  appendices  to  this  report. 

The  requirements  for  the  CY2006  software  development  from  the  white  paper  are 
presented  elsewhere  in  this  report;  however  the  conclusions  and  recommendations  are  repeated 
here  and  served  as  guidance  for  the  development  work  summarized  in  this  report. 
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Quoting  from  the  summary  section  of  the  (Garrood  2006)  white  paper: 


There  are  a  number  of  M&S  software  systems  that  have  been  developed  for  similar, 
but  limited,  physical  security  programs.  A  review  of  extant  anti-terrorism  M&S 
software  has  shown  that  the  technical  approach  in  the  ongoing  program  of  M&S 
development  at  the  Naval  Postgraduate  School  (NPS)  is  the  only  M&S  effort  that  is 
on  a  clear  path  to  meet  the  ATFP  Ashore  program  requirements.  Beginning  with 
the  waterside,  NPS  has  demonstrated  substantial  progress  toward  extending  their 
work  to  the  required  capabilities  over  the  entire  ATFP  Ashore  spectrum  of 
terrestrial,  air  and  waterside  threats,  systems  and  components. 

The  Naval  Postgraduate  School  M&S  tool  has  a  robust,  open-source  architecture 
embodied  in  software  and  resources  tailored  to  the  ATFP  Ashore  requirements.  It 
has  been  extended  to  become  the  evaluation  and  assessment  tool  required  by  the 
ATFP  Ashore  Systems  Engineering  team  to  perform  most  of  the  analytic  studies 
necessary  for  defining  ATFP  Ashore  system  risk,  vulnerability  and  consequence 
assessments  for  Naval  installations. 

In  short,  the  NPS  M&S  effort  is  both  necessary  and  sufficient  to  meet  the  ATFP 
Ashore  program  requirements. 

Therefore,  the  current  project  in  place  with  NPS  should  be  extended  and 
accelerated  to  meet  all  the  requirements  of  the  tool  set  and  ensure  that 
documentation  and  user  training  keep  pace  with  tool  development. 


3.3.2  S&ST  Team 

Dallas  Meggit 

Dennis  Garrood 
Mario  Pozzo 
Roger  Christiansen 
http://www.soundandsea.com 
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3.4  ANIVIZA 


3.4.1  Overview 

Aniviza,  Inc.  provided  technical  support,  implementation,  and  improvement  of  Viskit  and 
related  projects,  including  cluster  operations,  designs  of  experiments,  physically  based  sensor 
implementations  with  test  scenarios,  scenario  entities,  geometric  utilities,  user  interfaces  and 
package  installers. 


3.4.2  Activities  Performed 

Improvements  to  Gridkit,  the  cluster  component  to  Viskit's  experimental  design  feature 
included  transitioning  from  an  interpreted  to  a  compiled  runtime  to  support  more  complex 
parameterization  of  SMAL  entities.  This  required  some  redesign  of  the  Gridkit  boot  loader, 
which  sets  up  the  runtime  environment  for  each  node  run  in  order  to  import  compiled  classes 
from  Viskit  XML  entities  and  assemblies  as  opposed  to  translating  these  on-the-fly  with  the 
interpreter.  The  benefits  of  using  the  Java™  Beanshell  interpreter  were  mainly  that  it  simplified 
re-designation  of  the  class  pool  for  each  replication  without  having  to  reload  a  new  Java™ 
Classloader  each  time;  this  saved  implementation  complexity  as  well  as  runtime  startup 
overhead.  However,  the  interpreter  has  limitations  as  to  how  many  parameters  a  class  can 
consume  at  about  1/1  Oth  that  of  compiled  code,  so  the  Beanshell  interpreter  was  replaced  with  a 
standard  Javac  compiler  so  more  complex  entities  can  now  be  loaded  on  the  grid. 

Other  considerations  for  analysis  of  scenarios  were  addressed,  including  whether  the 
current  design  of  experiments  (DOE)  graphical  user  interface  (GUI)  was  sufficient  to  set  up 
parameters  for  a  nearly  orthogonal  Latin  hyper-sample  (Chioppa  2002).  The  current  mode  takes 
parameters  into  linearized  differentials  where  the  user  sets  high  and  low  endpoints,  but  does  not 
consider  the  use  of  other  shaped  random  variates  as  parameters;  part  of  the  difficulty  with 
varying  input  parameters  is  that  an  event-graph  agent  designer  may  not  see  a  particular  variate  as 
needing  to  be  non-constant,  however  it  may  be  selected  in  the  Viskit  DoE  panel  to  be  an 
independent  variate,  on  the  other  hand,  some  parameters  may  have  been  already  been  designated 
as  non-constant  variates  for  the  entity  by  use  of  an  explicit  randomizer  for  the  parameter  by  the 
designer.  If  the  designer  of  the  entity  was  correct,  then  all  one  should  want  to  do  is  set  some 
ranges  in  the  Viskit  Assembly  Editor,  run  either  locally  or  on  the  grid,  and  get  the  same  if  not 
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faster  results.  A  specialized  random  number  can  now  be  used  to  create  nearly  orthogonal  Latin 
hyper-samples  from  ordinary  Viskit  assemblies  for  cluster  runs  without  interaction  with  the 
Viskit  DoE. 

Further  work  needs  to  be  performed  on  the  DOE  panel  to  selectively  display  potential 
parameters  (based  on  entity  listener  patterns)  and  also  to  verify  and  validate  proper 
implementation  of  the  Latin  hyper-sample  algorithm. 

Part  of  the  Diskit  package  includes  support  for  mover  and  sensor  kinematics.  Sensors 
were  designed  to  be  pluggable  into  any  scenario;  however,  all  sensors  so  far  have  been  simple 
enter/exit  ranges.  This  is  insufficient  for  analysis  that  requires  more  accurate  assumptions  about, 
for  instance,  detectability  by  sonar  in  a  shallow  harbor,  where  such  ranges  may  vary,  or  be 
intermittent.  At  the  core  of  a  sonar  model  is  some  Figure  of  Merit  (FOM)  for  how  much  signal  is 
returned  in  a  meaningful  way  to  a  particular  operator,  which  then  describes  the  range  of  the 
sensor  at  that  exact  moment.  If  the  FOM  is  positive,  then  a  detection  has  happened;  likewise  if  it 
goes  negative  after  being  previously  detected,  then  it  is  undetected  (i.e.  contact  is  lost).  To 
maximize  the  number  of  possible  sensor  configurations  for  sampling  the  sonar,  e.g.  side¬ 
scanning  vs.  omni-directional,  or  skyward  for  radar,  a  geometrically  based  scan  approximation  is 
utilized.  This  algorithm  estimates  the  attenuated  transmission  loss  of  a  sonar  ping,  also  optimizes 
scheduling  for  detection  tests,  pings,  depending  upon  its  most  maximum  range  and  desired  scan 
shape,  while  still  being  a  drop-in  replacement  for  any  simpler  existing  Diskit  sensor. 

One  component  to  the  FOM  calculation  is  noise  sampled  at  a  location.  In  the 
MultiLRATLSonar  for  example,  noise  is  parameterized  by  a  random  variate.  In  the  sample  test 
case,  a  normal  random  variate  is  used,  however,  it  is  possible  to  take  geo-referenced  sample  data 
of  noise  using  an  InterpolatedXY Variate,  which  calculates  a  noise  level  based  upon  an 
interpolation  of  closest  sample  data.  The  design  of  the  InterpolatedXY  Variate  intended  for  fast 
updates  to  the  dataset,  so  that  noise  from  moving  objects  could  be  simulated  inexpensively.  See 
Appendix  E. 

Another  component  to  the  FOM  calculation  is  target  strength  (TS).  Target  strength 
depends  on  the  relative  rotation  of  the  target  and  its  size,  which  can  now  be  accessed  via  SMAL. 
The  current  implementation,  however,  is  assuming  constant  TS  as  more  work  was  needed  to 
easily  obtain  the  rotation  of  a  Mover. 
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Adding  vehicle  kinematics  and  propagation-based  sensor  predictions  to  a  DES  system  is 
highly  unusual  (and  perhaps  unique).  These  capabilities  greatly  improve  the  fidelity  of  the  most 
critical  interactions  being  modeled. 

Getting  Viskit  updates  out  to  a  user  base  has  so  far  been  via  a  Concurrent  Versioning 
System  (CVS).  This  is  insufficient  for  deployment  to  end  users.  A  new  auto-installer  builder  has 
been  incorporated  into  the  regular  Viskit  distribution  tasks.  Previous  installers  have  either  relied 
upon  using  commercial  freeware  that  have  become  obsolete,  or  upon  being  bundled  with  other 
installers.  Viskit  now  has  an  open-source  auto-installer  builder  as  part  of  the  build  process. 


3.4.3  Aniviza  Team 

Rick  Goldberg,  CEO 

http://www.aniviza.com 

3.5  DALY  REALISM 

3.5.1  Overview 

Daly  Realism  is  an  Internet  Consulting  company  that  provides  business  solutions  to  its 
clients.  Its  focus  is  on  secure  web  sites  that  deliver  the  right  user  experience.  The  company  uses 
the  latest  web  technologies,  including  interactive  3D  graphics  to  complete  it  solutions.  The 
principal  is  a  professional  member  of  the  Web3D  Consortium. 


3.5.2  Previous  Work 

Daly  Realism  has  worked  with  NPS  on  a  code  and  documentation  review  of  the 
SAVAGE  library.  All  of  the  X3D  code  was  reviewed  to  determine  compliance  with  the  X3D 
specification.  Code  that  was  not  compliant  was  identified  and  the  changes  needed  to  make  it 
compliant  were  documented.  The  documentation  structure  and  navigation  was  reviewed  and 
improvements  were  recommended  and  implemented. 
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3.5.3  Scope  of  Work 

Daly  Realism’s  Statement  of  Work  (SoW)  identified  one  major  task,  one  minor  task,  and 
a  number  of  small  project- administrative  tasks.  The  major  task  was  to  develop  application 
documentation  for  the  user-facing  applications  (SAVAGE  Studio  and  Viskit).  The  minor  task 
was  to  develop  training  and  instructional  materials.  The  project-administrative  tasks  include 
monthly  progress  reports,  regular  meeting  participation,  and  maintain  a  list  of  future 
improvements. 

During  the  project  kickoff  meeting,  it  was  determined  by  Sound  &  Sea  Technology,  NPS, 
and  NFCSE  that  providing  the  materials  listed  below  satisfied  the  SoW  for  the  major  and  minor 
tasks 

a.  Viskit  help,  including  a  tutorial  covering  the  various  uses  of  Viskit 

b.  SAVAGE  Studio,  including  a  tutorial  covering  the  various  uses  of  SAVAGE 
Studio 

c.  Frequently  Asked  Questions  (FAQ)  and  answers  for  high-level  questions  on  the 
project  and  application 

3.5.4  Activities  Performed 

All  of  the  application  help  was  developed  in  E1TML  &  CSS  to  work  with  the  embedded 
JavaFlelp™  system.  Viskit  help  comprises  90  cross-referenced  help  pages  in  standard  help 
hierarchal  format  with  screen  captures  to  illustrate  the  processes.  Included  in  the  90  pages  are  16 
pages  of  tutorials  showing  the  step-by-step  use  of  Viskit.  The  help  for  SAVAGE  Studio 
comprises  39  cross-referenced  help  pages  in  standard  help  hierarchal  format  with  screen  captures 
to  illustrate  the  processes.  Included  in  the  39  pages  are  5  pages  of  tutorials  showing  the  step-by- 
step  use  of  SavageStudio.  The  help  for  Viskit  and  SavageStudio  is  included  in  all  distributions  of 
the  applications. 
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3.5.5  Deliverables  Completed 

The  following  items  were  delivered  on  this  project. 

a.  Viskit  Help  -  90  HTML  pages  plus  55  images 

b.  SAVAGE  Studio  Help  -  39  HTML  pages  plus  20  images 

c.  FAQ  -  1  HTML  page 

d.  Monthly  status  reports  -  7  reports 

e.  Weekly  meeting  attendance  -  for  duration  of  project 

f.  Occasional  program  review  meetings  at  NPS  -  2  trips  to  Monterey 

g.  NPS  Open  House  and  ATFP  tutorial  -  1  trip  to  Monterey 

h.  Contributions  to  the  Final  Report 

3.5.6  Recommendations  for  Future  Work 

The  applications  for  this  project  are  built  and  distributed  using  the  Open  Source  model. 
That  model  has  been  shown  to  be  highly  responsive  to  user  questions  and  bug  reports  if  the  user 
and  developer  communities  are  large  enough.  If  clients  are  willing  to  pay  for  support  than  the 
size  of  those  communities  is  not  an  issue  (for  those  clients).  To  help  build  the  community  the 
following  suggestions  are  offered: 

ATFP  web  site:  SourceForge  is  an  excellent  location  for  developers  and  downloads  of 
installation  packages;  however,  it  does  not  provide  for  the  necessary  capabilities  to  support  a 
web-based  user  community.  The  ATFP  site  needs  to  offer  a  threaded  discussion  or  email  list  that 
is  open  to  all  users.  The  site  can  also  host  the  FAQ,  on-line  help,  tutorial,  and  other  use 
information. 

Context-Sensitive  Help:  Providing  help  to  the  user  that  is  sensitive  to  the  user’s  current 
situation  is  very  useful  for  improved  usability.  Ideally  the  help  that  is  provided  is  akin  to  an 
electronic  expert  in  that  the  help  sub-system  is  completely  aware  of  the  steps  the  user  has  already 
completed  and  what  the  user  needs  to  do  next. 

Facility  Building  Tool:  Daly  Realism  does  not  believe  that  a  user-oriented  tool  that 
builds  a  port  facility  should  be  a  recommendation  for  future  work.  On  occasions  a  tool  of  this 
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type  was  discussed,  but  dismissed  as  beyond  the  scope  of  this  project.  ATFP  is  used  by 
professional  doing  critical  risk-assessment  of  vital  facilities.  Allowing  non-experts  to  build  the 
port  runs  the  risk  of  severely  incorrect  decisions  being  made  based  on  incorrect  simulations. 
Developing  a  tool  that  would  allow  a  sufficiently  trained  individual  to  modify  features  of  an 
existing  port  is  useful.  This  can  allow  quick  response  to  changes  in  the  local  port  environment, 
such  as  dredging,  new  or  changed  piers  or  berths,  or  changes  to  breakwaters. 

3.5.7  Daly  Realism  Team 

All  work  on  this  project  was  performed  by  Leonard  Daly,  President. 

http://www.realism.com 

3.6  MEDIA  MACHINES 

3.6.1  Overview 

Media  Machines  is  a  leading  provider  of  technology  and  solutions  for  real-time  3D 
communication.  The  company  is  spearheading  the  development  of  standards  and  technologies 
that  lower  the  barrier  of  entry  and  total  cost  of  ownership  for  developing  real-time,  rich  media 
applications.  The  company  believes  that  3D  graphics,  integrated  with  rich  media  sources  such  as 
hypertext,  audio  and  video,  represents  the  next  step  in  human-computer  interaction.  The 
company  is  an  organizational  member  of  the  Web3D  Consortium. 

3.6.2  Scope  of  Work 

Visualization  capabilities  of  the  ATFP  Harbor  Security  Visualization  and  Analysis  Tool 
are  being  provided  using  the  Extensible  3D  Graphics  (X3D)  international  standard  for  3D 
graphics  on  the  Web.  Enhancement  of  X3D  authoring  tools  is  an  essential  part  of  the 
development  work  in  order  to  facilitate  development  of  the  visualizations. 

3.6.3  Activities  Performed 

X3D  Tool  Updates:  Updated  the  Flux  Studio  (formerly  Vizx3D)  Authoring  Tool  to  add 
support  for  Amendment  1  to  the  X3D  Specification,  specifically  [aligning  with  overall  Project 
SOW  para  4.1.7]: 
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Script  and  Proto  Editing.  The  tool  had  the  capability  to  Import,  Export,  and  Edit  Scripts 
and  Protos  in  the  Vizx3D  Beta.  The  remaining  tasks  were: 

•  To  support  editing  of  the  Proto  Body  using  the  native  Vizx3D  nodes  and  Render  the 
Proto  Body  within  Vizx3D.  The  Proto  Body  consisted  of  Generic  Nodes  which 
provided  the  user  the  ability  to  edit  any  of  the  Fields  of  the  Nodes,  but  there  was  no 
Node  Specific  GUI  that  Vizx3D  provided  for  the  Native  Vizx3D  Nodes.  Also,  these 
Generic  Nodes  were  not  rendered  inside  of  Vizx3D.  The  company  also  provided  a 
GUI  that  allows  users  to  specify  the  IS/Connect  constructs  within  the  Proto  Body. 

•  Provided  export  for  Protos  and  Scripts  in  the  Classic  VRML  encoding. 

Provided  support  of  IMPORT  and  EXPORT  statements. 

•  For  export,  provided  a  GUI  that  supports  specification  of  which  Nodes  in  the  scene 
will  be  exported  via  the  Export  Statement. 

•  For  import,  for  each  Inline  Node,  provided  support  for  looking  into  the  Inlined 
Content  (if  present)  to  generate  an  Import  Statement  that  corresponds  to  the  Export 
statement  found  in  the  Inlined  Content. 

Provided  support  for  Import,  Export,  Render  Elevation  Grid,  and  Triangle  Set  Nodes. 

Fixed  Import  and  Export  of  Extrusion  Node  (including  Rendering  within  Flux). 

Provided  support  for  Import,  Export,  Render  of  new  CAD  component  Nodes  and 
provided  edit  capability  for  Quad  Geometry  Nodes. 

Provided  support  for  Cubic  Environment  Maps  to  include  generation  of  Maps  within 
Vizx3D,  similar  to  the  current  support  for  generating  Spherical  Environment  Maps.  Included 
Rendering  within  Flux  and  support  for  rendering  within  Vizx3D. 


3.6.4  Media  Machines  AT/FP  Team 

Tony  Parisi,  President  and  CEO 

Keith  Victor,  Vice  President  of  Engineering 
http://www.mediamachines.com 
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3.7  OKINO  COMPUTER  GRAPHICS 


3.7.1  Overview 

In  one  sentence,  Okino  has  allocated  all  of  its  primary  programming  resources  to  the 
X3D  project  from  March  through  to  September  2006,  well  beyond  what  we  could  ideally 
allocate  to  one  single  project.  In  real  figures,  we  had  to  steal  development  time  from  2  other  key 
projects  (XAML  and  v5  release  cycle)  in  order  to  achieve  our  lofty  goals  for  the  X3D  project. 
Relatively  speaking,  the  100  hours  of  invoiced  work  time  covers  one  weekend  of  work,  and  just 
touches  on  some  of  the  overall  time  allocated  to  this  March-September  sub-project. 

We  are  highly  motivated  and  (in  essence)  fanatical  about  getting  our  bidirectional  X3D  + 
Classic  VRML  pipeline  1 00%  perfected.  Starting  in  1 999  VRML2  turned  out  to  be  one  of  our 
most  important  conversion  pipelines  for  our  PolyTrans  product,  and  hence  we  likewise  see  the 
need  and  reason  to  allocate  all  of  our  programming  resources  to  X3D  +  Classic  VRML  during 
2005  and  2006.  We  decided,  from  a  business  standpoint,  to  allocate  2005  and  2006  to  the 
development,  completion  and  refinement  of  this  X3D  project.  We  are  now  at  that  completion 
point  as  of  September  26th  2006. 


3.7.2  Primary  Task  Groups 

In  basic  terms,  our  time  allocation  has  been  spent  on  these  distinct  portions  of  the  X3D 

project: 

1)  Addition  of  new  capabilities  (import  +  export): 

•  3D  point  sets  (including  new  internal  PolyTrans  +  NuGraf  UI  display,  options 
and  save/load) 

•  3D  polylines  (including  new  internal  PolyTrans  +  NuGraf  UI  display,  options 
and  save/load) 

•  Classic  VRML  support 

•  ZLIB  compressed  output  capabilities  for  VRML1,  VRML2  and  X3D  and 
Inventor2 
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•  Removal  and  refinement  of  all  known  problems,  on  32-bit  and  64-bit 
platforms. 

•  Migration  to  using  the  faster  Microsoft  MSXML  v6 

2)  Coordination  of  the  release  of  Open  VRML  v0.16  from  Braden  McDaniel.  Okino 
developed  the  X3D  +  Classic  VRML  code  for  Open  VRML  v0.15  during  2005  (our  primary  task 
during  2005).  Braden  then  took  all  of  our  code  and  integrated  it  "his  way"  into  v0.15  from 
January  through  to  March  2006.  He  also  fixed  all  known  bugs  in  the  toolkit.  From  March  to 
September  2006  we  then  had  to  re-integrate  his  new  v0.16  initial  release  BACK  into  our  code 
line,  and  then  make  all  changes  necessary  to  make  the  new  codeline  compatible  to  what  we 
consider  "proper  X3D  support",  as  it  had  existed  in  the  Okino  version  of  Open  VRML  back  in 
December  2005.  The  sheer,  ultra  complexity  of  the  Open  VRML  toolkit,  and  its  1  hour  compile  + 
link  times,  made  this  the  most  horrendous  project  ever  taken  on  at  Okino,  bar  none.  As  of 
September  26th  we  finally  believe  the  v0.16  toolkit  is  commercially  viable  for  our  customers  to 
use.  Okino  does  not  release  any  software  until  we  can  personally  guarantee  a  software  solution  - 
at  this  point  in  the  evolution  of  our  own  X3D  converters  +  Open  VRML  combo;  we  believe  the 
end  to  end  solution  is  finally  working  nicely. 

3)  Porting  of  Open  VRML  to  the  Visual  Studio  VC2005  compiler.  Open  VRML  is  a  very 
heavy  templatized  toolkit  and  hence  refused  to  compile,  far  less  run,  on  VC 8.  This  was  a  real 
thorn  in  our  side  all  during  this  project.  We  would  rather  have  kept  with  VC7.1  but  in  order  to 
even  think  of  porting  to  64-bit  we  needed  to  first  get  the  codeline  running  on  VC8  Win32.  The 
VC7.1  version  of  v0.16  was  working  by  May  17  2006,  and  the  VC8  version  by  September  23rd 
2006. 

4)  Porting  of  Okino  X3D  +  Classic  VRML  +  VRML2  code  to  64-bit  architecture.  This 
was  tied  in  directly  to  the  initial  port  of  all  the  code  (import  and  export)  to  VC8.  The  exporters 
were  functional  by  Siggraph  2006.  However,  the  first  successful  execution  of  the  64-bit  importer 
code  (with  no  known  crashes)  only  occurred  on  September  23rd. 

5)  Re-engineering  of  our  various  installers  to  support  the  new  VC8  +  32/64-bit  versions 
of  the  VRML2+X3D  importer.  This  turned  out  to  be  a  real  fiasco.  A  simple  task  turning  into  a 
complete  task.  Our  new  code  requires  MSXML  v6  for  64-bit.  The  MSXML  installer  requires 
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Windows  Installer  v3.1.  Windows  Installers  v3.1  requires  that  Installshield  install  it  before  it 
executes  our  main  Okino  installer.  However,  a  "chicken  before  the  egg"  problem  occurs  with 
these  dependencies.  In  the  end  we  finally  opted  to  use  MSXMLv4  on  32-bits  and  MSXML  v6  on 
64-bits,  both  of  which  have  been  proven  to  be  functional.  This  may  allow  us  to  use  the  stock 
Microsoft  installers  without  requiring  the  end  users  to  upgrade  their  entire  operating  system  first. 
This  is  just  one  classic  problem  which  has  caused  the  X3D  project  to  consume  almost  every  hour 
of  our  development  time  this  summer. 

3.7.3  Main  Development  Achievements 

•  3D  point  sets  (including  new  internal  PolyTrans  +  NuGraf  UI  display,  options 
and  save/load) 

•  3D  polylines  (including  new  internal  PolyTrans  +  NuGraf  UI  display,  options 
and  save/load) 

•  Classic  VRML  support 

•  ZLIB  compressed  output  capabilities  for  VRML1,  VRML2  and  X3D  and 
Inventor2 

•  Migration  over  to  an  "Okino  qualified"  Open  VRML  vO.  16  toolkit,  which 
officially  includes  all  of  the  Okino  X3D  and  Classic  VRML  extensions  +  bug 
fixes. 

•  Final  release  version  of  our  X3D+VRML2+Classic-VRML  import  and  export 
converters  using  the  first  stable  release  of  Open  VRML  v0.16 

•  Porting  of  code  to  VC8  32-bit  and  64-bit. 

•  Modified  installers  to  support  this  new  version  of  Okino  X3D+VRML 
support. 

•  Migration  to  using  the  faster  Microsoft  MSXML  v6 
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3.7.4  Okino  AT/FP  Team 

Robert  Lansdale,  CEO 

Andrew  Grieve 

http://www.okino.com 

3.8  PLANET  9  STUDIOS 

3.8.1  Overview 

Planet  9  Studios  is  a  3D  products  and  content  company  focused  on  providing  real 
business  solutions  for  the  Internet.  The  company  has  produced  over  250  virtual  worlds  for  a 
variety  of  applications  such  as  marketing,  advertising,  product  visualization,  training, 
architectural  simulation,  military  simulation  and  entertainment.  It  is  constantly  incubating  new 
software  products  for  companies  and  helping  them  to  reach  market.  The  company  is  an 
Organization  Member  of  the  Web3D  Consortium. 

3.8.2  Previous  Work 

Planet  9  Studios  has  worked  with  the  US  Navy  for  several  years,  developing  high-fidelity 
models  and  software  systems  for  a  variety  of  needs.  This  includes  development  of  world-class 
models  as  part  of  the  Anti-Terrorism/Force  Protection  (AT/FP)  team. 

In  October  2004,  the  company  was  tasked  with  the  development  of  a  fully  textured 
Extensible  3D  (X3D)  model  of  the  Al-Basrah  Oil  Terminal  (ABOT)  and  the  surrounding  area  for 
the  purpose  of  evaluating  scenarios  in  the  protection  from  surface  threats.  This  project  was 
originally  known  as  Gas  and  Oil  Platforms  (GOPLATS). 

In  April  2005,  the  company  was  contracted  to  develop  two  additional  X3D  models  for  the 
AT/FP  effort,  during  Phase  I  of  this  project.  These  were  high-fidelity  models  of  two  Navy 
facilities  in  Washington  State,  specifically  NAVSTA  Bremerton  and  NAVMAG  Indian  Island. 
These  models  included  geo-referenced  terrain  as  well  as  a  number  of  photo-realistic  shore-side 
3D  buildings  and  structures.  Several  models  of  watercraft  were  also  developed  as  part  of  this 
deliverable.  These  combined  models  were  used  as  the  primary  test-bed  scenarios  in  the 
continuing  development  of  the  AT/FP  software. 
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3.8.3  Scope  of  Work 

In  February  2006,  Planet  9  Studios  received  a  scope  of  work  (SOW)  for  Phase  II  of  the 
Modeling  and  3D  Visualization  for  Evaluation  of  Anti-Terrorism/Force  Protection  Alternatives. 
The  scope  was  an  order  of  magnitude  greater  than  Phase  I,  which  included  revisions  of  Phase  I 
deliverables,  as  well  as  the  development  of  new  X3D  models  of  waterside  buildings  and  terrain 
at  both  Pearl  Harbor  and  Port  Hueneme.  Additionally,  the  SOW  included  supporting  roles  in  the 
tasks  of  analysis  tool  development,  training  and  documentation,  as  well  as  the  necessary  team 
coordination  and  management. 

However,  the  full  level  of  funding  required  to  meet  every  task  described  in  the  SOW  was 
not  available.  Planet  9  Studios  was  awarded  a  Purchase  Order  for  approximately  48%  of  the  total 
amount  quoted  as  being  required  to  complete  all  of  these  tasks.  The  company  worked  with  the 
customer  and  the  team  to  prioritize  the  tasks,  and  made  a  determination  that  the  following  items 
would  be  undertaken  with  the  available  funds: 

•  Pearl  Harbor  -  construction  of  X3D  model  for  Waterside  Security  Visualization 

•  On-site  Training  -  provide  one  on-site  training  in  the  use  of  AT/FP  software 

•  Team  Coordination  -  project  management,  reporting,  and  conference  attendance 

Those  items  removed  from  the  list  of  expected  deliverables  were  the  following: 

•  Indian  Island  and  Bremerton  -  enhancement  of  Phase  I  modeling 

•  Port  Hueneme  -  construction  of  X3D  model  for  Waterside  Security  Visualization 

•  Analysis  Tool  -  contribution  to  design,  development,  testing,  and  demonstration 

•  Off-site  Training  -  provide  off-site  training  in  the  use  of  AT/FP  software 

As  the  project  proceeded,  some  additional  task  items  were  requested  by  the  customer. 
Where  possible  these  requests  were  accommodated  by  making  non-critical  adjustments  to  the 
requirements  of  the  existing  tasks.  These  are  called  out  below. 
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3.8.4  Activities  Performed 

Pearl  Harbor  Waterside  Security  Visualization  (Bug  #989)  -  Planet  9  Studios  was 
given  notice  to  proceed  on  March  7,  2006.  Prior  to  this,  the  company  had  received  the 
prerequisite  technical  drawings  and  other  source  data  from  Naval  Facilities  Engineering 
Command  (NAVFAC).  A  company  photographer  was  dispatched  to  Pearl  Harbor  to  take 
pictures  of  the  buildings  and  structures  located  in  the  area  of  interest.  These  photos  would  serve 
as  both  a  visual  reference  and  as  the  source  for  texture  maps  to  be  applied  to  the  3D  building 
models,  in  order  to  give  them  a  photo-realistic  appearance.  (Data  collection  was  identified  as 
Bug  #978) 

A  geo-referenced  X3D  terrain  model  of  Oahu  was  developed  using  10-meter  SDTS 
Digital  Elevation  Model  (DEM)  source  files.  This  was  draped  with  color-corrected  30-meter 
Land  Remote-Sensing  Satellite  (LANDSAT)  imagery.  To  the  immediate  area  around  Pearl 
Harbor,  topographic  data  was  integrated  into  the  greater  terrain  model.  This  higher-resolution 
area  was  draped  with  1  -meter  imagery  originating  from  Space  Imaging,  and  included  the  Naval 
Station,  Naval  Shipyard,  SUBASE,  FISC,  and  Ford  Island  facilities.  The  resulting  geometry  was 
then  optimized  for  real-time  rendering,  including  the  addition  of  Levels  of  Detail  (LOD)  for 
increased  efficiency,  and  geo-referenced  within  the  Universal  Transverse  Mercator  (UTM) 
coordinate  system.  The  rendering  system,  Xj3D,  required  these  to  be  converted  to  a  terrain 
specialized  form  of  the  X3D  node,  called  “GeoLOD”. 

Upon  the  terrain  were  constructed  X3D  models  of  the  majority  of  Navy  buildings  visible 
from  the  water,  as  well  as  piers  and  wharves  attached  to  the  facilities.  The  location  and  footprint 
of  each  structure  was  extracted  from  the  provided  computer-aided  drafting  (CAD)  files,  which 
had  been  aligned  with  the  geo-referenced  terrain.  The  footprints  were  extruded  and  modified  to 
create  a  representational  geometric  model  of  each  structure.  To  these  were  applied  texture  maps 
derived  from  the  location  photographs,  thereby  resulting  in  a  photo-realistic  model  for  use  in  the 
AT/FP  simulation  software.  For  ease  of  management,  the  buildings  were  grouped  into  a  limited 
number  of  separate  files  based  upon  location.  It  was  determined  that  providing  each  individual 
structure  in  a  separate  file,  as  originally  requested,  would  have  been  too  burdensome  given  the 
amount  of  work  that  would  have  been  required.  This  allowed  for  the  assigned  funds  to  be 
redirected  to  other  additional  tasks. 
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Similar  to  the  topographic  terrain,  bathymetric  geometry  was  developed  using  vector- 
based  CAD  files  as  the  source  data.  These  describe  the  depth  of  the  harbor  floor  with  contours  at 
regular  intervals.  From  these,  a  3D  mesh  was  created  and  optimized.  However,  this  model  was 
not  integrated  into  the  final  scene.  Higher  resolution  bathymetric  data  in  Digital  Nautical  Chart 
(DNC)  format,  supplied  by  the  Naval  Undersea  Warfare  Center  (NUWC),  was  able  to  be  loaded 
directly  into  Xj3D  by  the  team  at  Naval  Postgraduate  School  (NPS). 

A  series  of  Aids  to  Navigation  (ATON)  X3D  PROTO  models  was  produced  to  allow  the 
virtual  waterways  to  be  populated  with  charted  marks  as  they  are  in  the  actual  world.  The 
selection  included  various  buoys,  lights,  daybeacons,  and  range  lights  that  can  now  be  positioned 
and  oriented  at  precise  locations  within  a  given  scene.  When  applicable,  certain  models  contain 
switches  to  allow  assignment  of  a  few  specific  attributes  such  as  port  (green)  vs.  starboard  (red), 
light  on  vs.  light  off,  and  brightness  of  light  glow.  An  X3D  scene  was  laid  out  using  these  ATON 
models  to  reflect  the  actual  lay  out  of  marks  at  Pearl  Harbor,  according  to  GIS  data  describing 
the  exact  location  and  identity  of  these.  This  data  was  obtained  from  the  public  website  of  the 
National  Oceanic  &  Atmospheric  Administration  (NOAA). 

As  an  addendum  to  the  SOW  (via  Bug  #1009),  Planet  9  Studios  was  asked  create  a  2D 
compass  rose  for  general  direction  finding,  to  be  displayed  in  a  Heads-Up  Display  (HUD) 
manner  over  any  given  X3D  scene.  This  consisted  of  a  texture  mapped  compass  face  which 
rotated  in  direct  correlation  with  the  orientation  of  the  user’s  viewpoint.  While  the  visual 
components  were  complete  with  basic  functionality  in  place,  the  file  was  not  finished  as  of  this 
report.  There  remains  an  issue  of  gimbal  lock  in  the  compass  rotation,  due  to  the  fact  that  it  is 
tied  to  the  viewpont  orientation  via  the  X3D  “ProximitySensor”  node.  The  visual  artifact  is  not 
noticeable  when  the  viewpoint  is  parallel  to  the  ground,  but  becomes  apparent  when  viewpoint  is 
pitched  up  or  down.  A  quaternion  approach  may  need  to  be  implemented  in  order  to  alleviate  this 
issue. 

The  request  was  also  made  (via  Bug  #537)  of  Planet  9  Studios  to  provide  a  copy  of  its 
previously  existing  X3D  PROTO  of  the  Port  Security  Barrier  (PSB)  for  release  into  open  source, 
thereby  allowing  it  to  be  freely  used  and  modified.  A  portion  of  the  funding  was  redirected  from 
other  tasks  to  provide  compensation  for  this  transfer  of  intellectual  property.  The  PSB  model  was 
reviewed  and  released,  after  minor  refinements. 
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Finally,  Planet  9  Studios  coordinated  with  project  partners  to  achieve  necessary  results. 
The  company  worked  closely  with  Yumetech  not  only  to  integrate  the  X3D  models  into  its  Xj3D 
real-time  rendering  environment,  but  also  to  sort  out  various  technical  issues,  including  geo¬ 
location,  naming  conventions,  headers,  LODs,  metadata,  lighting,  and  bug  identification.  To  a 
lesser  extent  Planet  9  Studios  also  worked  with  Daly  Realism,  providing  some  minor  assistance 
with  the  Help  System  they  developed  for  the  software. 

Training  and  Documentation  (Bug  #986)  -  Planet  9  Studios  was  originally  asked  to 
provide  a  hands-on  tutorial  targeted  towards  prospective  force  protection  officers  and  users  of 
the  AT/FP  software,  with  an  emphasis  on  more  advanced,  analyst  type  levels  of  technical 
experience.  Based  on  expected  changes  in  the  prospective  audience,  the  focus  of  the  tutorial  was 
changed  to  include  a  more  general  overview  of  the  code  and  data  structures  that  the  system  runs 
on.  The  objective  was  to  give  prospective  users  a  good  idea  of  the  underlying  system  and  allow 
more  advanced  users  a  glimpse  into  the  ease  with  which  the  system  can  be  extended. 

The  process  involved  collaborating  with  LT  Pat  Sullivan  of  the  Naval  Postgraduate 
School  (NPS)  on  basic  VisKit  examples,  as  well  as  obtaining  a  simple  DES  example  used  to 
illustrate  the  basic  principles  underlying  the  simulation  system.  The  two  example  scenes 
illustrate  the  most  simple  event  graphs  and  assemblies  possible  to  run  the  system  with.  Most  of 
the  material  in  the  AT/FP  software  tutorial  slides  was  generated  from  these  examples. 

The  first  milestone  was  the  initial  draft  of  the  tutorial,  delivered  on  September  12,  2006. 
The  second  milestone  was  the  delivery  of  the  second  version  of  the  tutorial,  delivered  on  August 
1,  2006.  The  primary  deliverable  was  the  tutorial  itself,  which  was  made  available  via  the  Planet 
9  Studio  website  as  well  as  presented  in  person  at  the  August  7,  2006  AT/FP  software  tutorial 
session  at  the  MOVES  Open  House,  fulfilling  our  supporting  role  in  developing  the  project 
documentation.  The  tutorial  was  developed  using  the  open-standards  based  s5  presentation 
system. 

Future  directions  for  work  should  primarily  include  feedback  from  a  broader  array  of 
potential  users.  Future  versions  of  the  tutorial  will  be  more  hands  on  and  comprehensive. 
Delivery  of  this  sort  of  tutorial  can  play  a  critical  role  in  detecting  and  repairing  usability  issues. 

Team  Coordination  and  Management  -  Planet  9  Studios  began  the  project  by 
contributing  to  the  Plan  of  Action  and  Milestones  (POA&M).  The  regular  administration  of  this 
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project  included  weekly  teleconferences  with  the  team,  with  occasional  project  review  meetings 
onsite  at  the  Naval  Postgraduate  School  (NPS)  in  Monterey,  CA.  Technical  issues  were  reported, 
assigned,  and  tracked  using  Bugzilla  software.  Detailed  status  reports  were  submitted  after  the 
end  of  each  month,  as  well  as  contributions  to  this  final  report.  Additionally,  Planet  9  Studios 
was  asked  to  participate  in  a  selection  of  professional  conferences  during  the  period  of 
performance. 

Representatives  of  the  company  attended  the  Anti-Terrorism/Force  Protection  (AT/FP) 
Ashore  Modeling  and  Simulation  (M&S)  Workshop  at  NPS  on  May  9-11,  2006,  an 
informational  forum  of  M&S  professionals  working  in  the  service  of  naval  installation  security. 
David  Colleen,  CEO,  Planet  9  Studios,  gave  a  presentation  entitled,  “3D  Geospatial  Data 
Interfaces  &  Tools”  which  discussed  the  various  methodologies  used  by  the  company  to  provide 
solutions  to  its  customers  within  the  M&S  market. 

For  the  MOVES  Open  House,  held  at  NPS  on  August  8-10,  2006,  Planet  9  Studios  was 
again  in  attendance.  A  tutorial  for  the  AT/FP  software  was  held  on  the  previous  day  during 
which  Dan  Ancona,  Planet  9  Studios,  presented  the  instructional  “Port  Security  Simulation  with 
SAVAGE  Studio”,  demonstrating  fundamentals  of  the  software  with  examples  and  code. 
Christian  Greuel,  Planet  9  Studios,  presented  a  high-level  overview  of  the  production  process  for 
creating  geo-referenced  models,  entitled  “Building  Geo-Registered  X3D  -  Port  &  Harbor 
Models. . .  Accurately  Located”.  The  company  also  participated  in  the  Demo  Night  by 
showcasing  several  examples  of  work  that  have  been  completed  for  the  various  phases  of  the 
AT/FP  project. 


3.8.5  Deliverables  Completed 

In  the  course  of  its  performance  of  the  contract  for  Phase  II  of  the  Modeling  and  3D 
Visualization  for  Evaluation  of  Anti-Terrorism/Force  Protection  Alternatives,  Planet  9  Studios 
completed  and  delivered  the  following  items: 

•  Input  to  the  Plan  of  Action  and  Milestones  (POA&M) 

•  Geo-referenced  Buildings  and  Terrain,  X3D  models  with  texture  maps: 

o  Pearl  Harbor  /  Oahu  terrain,  including  GeoLODs,  and  piers  &  wharves 
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o 


NAVSTA/SUBASE/FISC  buildings 
o  Naval  Shipyard  buildings 
o  Ford  Island  buildings 
o  Extra  buildings  (Lochs) 
o  Ford  Island  Bridge 

•  Aids  to  Navigation,  X3D  PROTO  models  with  texture  maps: 
o  Daybeacon 

o  Lighted  Buoy 
o  Light  Post 
o  Light 
o  Range  Light 

o  Danger  Daybeacon  (non-PROTO) 

•  Aids  to  Navigation,  Sample  Layouts,  X3D  models: 
o  Pearl  Harbor  Navigation  Aids  (Geo-referenced) 
o  Navigation  Aids  Example  (Generic  example) 

•  Buoys,  X3D  models  with  texture  maps: 
o  Marker  Buoy 

o  Mooring  Buoy 

•  Port  Security  Barrier,  X3D  PROTO  model,  released  as  open  source 

•  Compass  Rose,  X3D  PROTO  and  example,  VRML  format  (incomplete  code) 

•  AT/FP  software  installation  script 

•  Slide-sets  from  AT/FP  Ashore  M&S  Workshop  presentations 

•  Slide-sets  from  AT/FP  software  tutorial  presentation 

•  Findings  from  Savage  /  SavageDefense  archives  file  verification 
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•  Monthly  Status  Reports 

•  Contributions  to  Final  Report 


3.8.6  Recommendations  for  Future  Work 

Much  progress  has  been  made  in  the  first  two  phases  of  the  Modeling  and  3D 
Visualization  for  Evaluation  of  Anti-Terrorism/Force  Protection  Alternatives  effort.  To  build 
upon  this  success,  the  following  enhancements  are  suggested. 

Items  removed  from  Phase  II  -  The  project  would  benefit  from  attending  to  those  tasks 
which  were  not  able  to  be  addressed  within  the  allotted  funding  for  Phase  II.  These  include: 

•  Indian  Island  and  Bremerton  -  enhancement  of  Phase  I  modeling 
o  increased  fidelity  of  terrain  imagery 

o  addition  of  more  site-specific  buildings 
o  inclusion  of  foliage 
o  other 

•  Port  Hueneme  -  construction  of  X3D  model  for  Waterside  Security  Visualization 

•  Analysis  Tool  -  contribution  to  design,  development,  testing,  and  demonstration 

•  Off-site  Training  -  provide  off-site  training  in  the  use  of  AT/FP  software 

Conversion  of  existing  ports  -  Planet  9  Studios  has  previously  developed  a  variety  of 
US  Navy  specific  3D  content,  to  which  the  company  has  maintained  ownership  of  the 
intellectual  property  rights.  Approximately  half  of  this  data  exists  in  X3D  format,  while  the  other 
half  is  in  the  older  VRML97  format.  So  that  these  models  might  achieve  the  widest  possible  use, 
it  is  suggested  that  they  are  1)  geo-referenced,  2)  converted  to  X3D  format,  if  applicable,  and  3) 
moved  into  the  realm  of  open  source,  to  be  served  from  the  Savage  and  SavageDefense  (FOUO) 
X3D  Archives.  The  models  to  which  this  currently  applies  are  of  the  following  locations: 

•  Al-Basrah  Oil  Terminal  (ABOT) 

•  Friday  Harbor,  WA  (civilian) 

•  MCAS  Miramar 
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•  NAS  North  Island  (rough) 

•  NAVMAG  Indian  Island  (earlier  work) 

•  NAVSTA  Norfolk  (coming  soon) 

•  Pearl  Harbor 
o  Terrain 

o  Ford  Island  Buildings 
o  Ford  Island  Bridge 
o  Arizona  Memorial 

•  Port  Hueneme  (rough) 

.  SUBASE  Bangor 

o  Marginal  Wharf 
o  Delta/Drydock 
o  Service  Pier 

o  Explosives  Handling  Wharf 

•  Washington  Navy  Yard 

•  Yokosuka,  Japan 

Creation  of  new  ports  -  In  addition  to  these  pre-existing  assets,  Planet  9  Studios  would 
be  able  to  provide  any  number  of  new  X3D  port  facilities.  This  could  include  any  or  all  real- 
world  facilities,  either  CONUS  or  OCONUS,  that  would  benefit  from  utilizing  the  AT/FP 
visualization  system.  It  could  also  include  generic,  non-specific  ports  that  might  be  used  for 
examples  and  software  training  scenarios. 

Aids  to  Navigation  (ATON)  -  Create  a  comprehensive  system  of  X3D  PROTO  models 
with  attributes  adherent  to  International  Hydrographic  Organization  (IHO)  S-57 
(http://www.caris.com/s-57).  This  standard,  prepared  by  the  IHO  Committee  on  Hydrographic 
Requirements  for  Information  Systems  (CHRIS),  is  for  the  coding  and  exchange  of  hydrographic 
digital  data.  The  X3D  PROTOS  would  include  defined  options  such  as  numeric  designation, 
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types  of  sounds,  and  precise  light  flashing  characteristics.  The  system  would  include  a  more 
complete  selection  of  ATON  types  (e.g.  Cans/Nuns,  Mileboards,  Warning  Markers,  etc).  See 
Appendix  G. 

Automation  -  The  following  production  items  would  benefit  from  development  of 
automation  processes: 

•  Automatic  editing  of  X3D  files  to  include  multiple  alternate  URLs  for  textures  maps 

•  Automate  editing  of  X3D  files  to  include  multiple  alternate  URLs  for  ExtemProto 
files  under  the  “ExterProtoDeclare”  node 

•  Automate  separation  of  individual  geometries  in  the  scene  (e.g.,  platforms,  buildings, 
piers,  etc.)  into  separate  files  that  can  be  inlined  and  geo-positioned  into  other  scenes 
and  not  tied  specifically  to  the  subject  scene. 

Miscellaneous  -  In  addition  to  the  above,  the  following  tasks  are  also  suggested  as  future 
work  for  this  continuing  effort: 

•  Addition  of  visual  effects,  explosions,  gun  fire,  time  of  day,  weather. 

•  Fix  all  older  X3D  headers,  e.g.  ABOT,  Bremerton,  Indian  Island,  boats 

•  Move  Compass  Rose  to  HUD  layer 

•  Write  a  “How  to  Build  an  X3D  City  Model”  white  paper. 

3.8.7  Planet  9  Studios  AT/FP  Team 

David  Colleen,  Chief  Executive  Officer 

Christian  Greuel,  Director  of  Art  &  Production 

Dan  Ancona,  Software  Engineer 

Danny  Lee,  3D  Artist 

Carlos  Newcomb,  3D  Artist 

Ken  Rhee,  3D  Artist 

Alberto  Rodriguez,  Office  Manager 

http://www.planet9.com 
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3.8  SONALYSTS 

Noteworthy  contributions  to  the  sonar  model  design  were  provided  by  Sonalysts,  Inc.  All 
design  work  was  coordinated  by  NPS.  See  Appendix  E  for  a  rigorous  design  summary  of  sonar 
physics  modeling. 


3.8.1  Overview 

For  more  than  25  years,  Sonalysts  has  developed  solutions  in  computer  software  design 
and  implementation,  telecommunications  research  and  analysis,  prototype  development  and 
manufacturing,  multimedia  design  and  editing,  animation,  intelligent  training  systems,  weather 
products,  commercial  nuclear  power  safety  and  quality  assurance,  and  naval  systems  analysis 
and  operations  research. 


3.8.2  Progress  to  date: 

Sonalysts  researched  unclassified  sources  for  parameters  and  techniques  appropriate  for 
acoustically  modeling  shallow,  noisy  waters  at  high  frequencies.  Sonalysts  provided  Aniviza 
with  a  description  of  the  sonar  equation  and  value  estimates  for  various  parameters.  Cylindrical 
spreading  plus  frequency  dependent  attenuation  was  selected  to  provide  initial  estimates  of 
acoustic  transmission  loss.  While  quick  to  calculate  and  reasonably  accurate,  a  more 
sophisticated  alternative  to  represent  transmission  loss  has  also  been  considered.  The 
Comprehensive  Acoustic  Simulation  System  (CASS)  was  studied  as  a  more  sophisticated 
alternative  to  the  aforementioned  cylindrical  spreading  plus  frequency  dependent  attenuation.  A 
CASS  input  stream  was  developed  to  estimate  transmission  loss  in  the  vicinity  of  Port 
Townsend/Indian  Island. 

3.8.3  Recommendations  for  future  work 

Refinement  of  the  spreading  +  attenuation  model  should  be  possible  using  CASS  results 
as  a  guide.  Furthermore,  the  CASS  results  themselves  can  be  improved  by  using  measured 
sound  speed  profiles,  bathymetry,  and  bottom  type  for  the  various  harbors  of  interest. 
Unclassified  descriptions  of  appropriate  sonar  systems  should  also  be  sought. 
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3.8.4  Sonalysts  Team 

Margaret  Bailey 

Doug  Nelson 

http://www.sonalysts.com 

3.9  YUMETECH 

3.9.1  Progress  to  Date 

At  the  end  of  this  phase  of  project,  Yumetech  made  significant  progress  on  a  number  of 
key  areas.  As  well  as  the  development  directly  related  to  the  ATFP  simulation  system,  the 
company  made  significant  updates  to  its  Xj3D  and  Aviatrix  toolkits.  These  changes  significantly 
improved  the  performance  of  the  software  and  made  future  changes  to  the  software  easier  to 
incorporate.  Yumetech  also  added  a  number  of  features  to  the  ChefX3D  toolkit  to  expand  its 
functionality. 

MOVES  Institute  members  added  invaluable  input  with  regards  to  software  bugs  and 
implementation  problems  through  regular  telephone  conference  calls.  Moreover,  MOVES 
content  provided  useful  material  for  testing  the  Xj3D  source  code.  Yumetech  was  able  to  make 
adjustments  to  the  code  to  correct  the  bugs  discovered  in  these  tests. 

At  the  beginning  of  this  project,  simulation  developers  had  to  employ  several  separate 
and  distinct  software  tools  to  generate  a  scenario.  One  of  these  components — a  3D  modeling 
tool — typically  requires  a  fairly  expert  user.  At  the  end  of  this  Phase,  Yumetech  has  successfully 
created  a  fully  integrated  tool  that  allows  a  non-expert  user  to  author  a  scenario  using  one  of  the 
pre-defined  ports.  Moreover,  one  can  change  all  SMAL  parameters  and  some  agent  specific 
simulation  parameters  and  then  can  launch  a  3D  overview  of  a  simulation  and/or  run  the  scenario 
for  statistics  analysis. 

a.  Yumetech  has  accomplished  the  following  during  this  project: 

b.  Upgraded  the  ATFP  3D  visualization  software  to  Xj3D  version  2.0. 

c.  Upgraded  the  ATFP  3D  visualization  software  to  Aviatrix3D  2.0. 

d.  Added  the  prototype  3D  editing  viewer. 
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e.  Provided  zoom  and  pan  capabilities  in  main  view  window. 

f.  Developed  an  Ortho  Viewpoint  for  top-down  photos  of  3D  scene. 

g.  Completed  the  integration  of  the  Pearl  Harbor  Model  into  the  software. 

h.  Added  screenshots  and  conversion  factors  capabilities. 

i.  Fixed  Xj3D  issues  discovered  with  new  Pearl  Harbor  model. 

j.  Created  an  end-user  install  package  to  facilitate  software  installation. 

k.  Re-architected  ChefX3D  to  support  new  features 

i.  Added  support  for  segment  tools  (Fence,  Barrier). 

ii.  Added  support  for  segment  property  panels. 

Yumetech  completed  the  following  assigned  tasks  during  this  project: 

a.  Port  and  Port  Facility  Modeling. 

i.  Indian  Island  and  Bremerton,  Washington  Waterside  Security  Visualization. 

ii.  Pearl  Harbor  and  Port  Hueneme  Waterside  Security  Visualization. 

b.  Analysis  Tool  Development. 

i.  Integration  with  AUVW. 

ii.  GUI  for  Scenario  Set-up. 

iii.  Configuration  Control. 

c.  Follow-on  Requirements. 

The  Phase  Two  work  required  that  certain  components  be  completed  before  others. 
Because  of  task  priorities  and  additional  requirements  arising  from  the  development  process,  the 
following  tasks  were  not  completed  in  this  phase: 

a.  DNC  Load/Display. 

b.  Physics-Based  Models  (some  work  on  this  component  was  done,  but  the  task  is 
not  completed). 

c.  NMCI/IT-21. 
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3.9.2  Future  Development 

Yumetech  sees  the  next  phase  of  development  on  this  project  as  the  one  that  will  bring 
the  ATFP  simulator  to  a  fully  deployable  stage.  As  well  as  completing  the  tasks  left  from  the 
Phase  Two  work,  the  company  has  identified  a  number  of  areas  that  would  further  enhance  the 
usability  and  flexibility  of  this  already  invaluable  tool.  These  areas  are: 

a.  Location  set-up. 

b.  Barrier  representation. 

c.  Property  editor. 

d.  Statistical /Visualization  tool  improvements. 

e.  3D  viewer  improvements. 

f.  Automating  the  Integration  of  Savage  Studio  with  the  Savage  Library. 

g.  Environmental  Effects. 

3.9.2. 1  Location  Set-up 

Currently,  creating  new  scenario  locations  such  as  port  facilities  and  military 
bases  requires  3D  modeling  experts  to  create  these  models  at  a  premium  cost.  Yumetech 
proposes  the  development  of  a  set  of  modeling  tools  that  will  allow  non-3D  graphics  experts  to 
create  their  own  scenario  locations.  These  tools  will  make  use  of  geo-spatial  and  satellite  data  as 
well  as  a  model  database  that  will  allow  end-users  to  easily  create  terrain  models  and  place 
buildings,  port  facilities,  and  other  assets  with  relative  ease.  This  work  can  be  integrated  with  the 
X3D  Earth  effort  to  facilitate  this  task. 

Yumetech  also  sees  the  following  components  as  key  elements  of  this  task: 

a.  Fences — create  a  fence  model/behavior. 

b.  Checkpoints — Create  a  check  point  model/behavior. 

c.  Building  Authoring — Develop  an  easy  interface  to  create  simple  buildings. 

The  Google  Sketchup  interface  is  a  good  example. 
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3. 9. 2. 2  Barrier  Representation 

The  current  barrier  models  need  further  improvement  to  be  effective  in  simulation 
assessment.  The  current  barrier  models  need  a  SMAL  representation.  Moreover,  the  top-down 
visual  representation  of  the  3D  model  needs  significant  improvement.  Finally,  the  visual 
response  of  boat  models  should  use  real-time  physics  for  realistic  response  characteristics. 

3. 9. 2. 3  Property  Editor 

Savage  Studio  needs  to  parse  the  Viskit  event  graph  file  and  use  that  information 
to  populate  a  new  tab  on  the  property  editor  panel.  Currently,  a  restricted  interface  is  in  place  to 
handle  Patrol  Zones.  This  interface  needs  to  be  generalized  in  order  to  make  the  system  more 
useful. 

Moreover,  the  current  system  parses  an  XML  instance  to  develop  the  parameter 
space  in  the  following  manner: 

Communications  channel="2"  address="124 . 134 . 89 . 2"/> 

Yumetech  proposes  that  parsing  a  schema  would  greatly  improve  the  utility  of  the 
property  editor.  Such  a  scheme  would  allow  the  addition  of  applnfo  components  for  adding 
features  such  as  Data  Editors  (e.g.,  File  Dialog  boxes).  The  applnfo  tag  identifies  what  special 
editor  the  system  must  use  in  a  particular  instance.  Making  this  change  would  also  allow  the 
system  to  pull  the  allowed  values  to  populate  a  combo  box.  A  possible  scheme  example  would 
look  like  the  following: 

<xs: element  name="Channel"> 

<xs : complexType  mixed="false"> 

<xs : attribute  name="channel"  type="xsd: integer"  appInfo="NumberEditor"> 
<xs : attribute  name="addressed"  type="xsd: string" 
appInfo="InternetAddressEditor"> 

</xs : complexType> 

</xs : element> 
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3. 2. 9. 4  Statistical/Visualization  Tool  Improvements 

The  current  system  requires  users  to  select  entities  to  track  in  the  statistics  tool  in 
Viskit.  A  better  way  to  accomplish  this  task  would  be  to  allow  users  to  select  entities  for 
analysis  using  Savage  studio.  This  change  would  provide  end-users  with  a  more  intuitive, 
graphical  interface  for  this  task. 

The  visualization  tool  for  the  review  specific  scenarios  should  allow  end-users  to 
select  a  specific  run  of  a  scenario  and  review  it  in  the  3D  viewer.  This  ability  would  allow  users 
to  examine  and  analyze  anomalies  in  the  statistical  runs  to  determine  weaknesses  in  the  defense 
plan.  This  capability  needs  to  be  added  to  the  current  system. 

The  system  would  also  benefit  from  a  2D  View  of  the  scenario.  The  system 
should  provide  2D,  so  that  top-down  view  of  the  scenario  incidents  can  be  viewed  by  the  user. 
This  ability  might  be  accomplished  using  an  orthographic  view  of  the  3D  scene. 

3.9.2. 5  3D  Viewer  Improvements 

Yumetech  has  identified  a  number  of  areas  to  improve  the  usability  of  the  3D 
viewer.  These  include: 

a.  Improving  texture  loading  to  improve  performance  on  lower-end  machines. 

b.  Optimizing  memory  usage  so  larger  areas  can  be  modeled. 

c.  Implementing  a  complete  (MIL-STD)-2525A  for  Unit  descriptor  top-down 
view. 

d.  Integrate  X3D  Binary  generation  and  loading 

Yumetech  also  believes  that  providing  a  tree  view  of  the  entities  of  a  scene  can 
make  it  easier  to  edit  some  worlds.  This  tree-view  should  allow  deletion  of  entities.  Moreover, 
selecting  an  entity  should  bring  its  parameters  up  for  editing  in  the  property  editor. 

Moreover,  Yumetech  believes  that  end-user  utility  can  be  significantly  enhanced 
by  employing  a  number  of  viewpoint  interface  enhancements.  Better  viewpoint  selection  can  be 
created  by  assigning  a  keyboard  interface  for  selecting  high/med/low  viewpoints.  Usability  can 
also  be  improved  by  implementing  the  ViewpointGroup  node.  Other  viewpoint  improvements 
include: 
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a.  Provide  better  options  for  selection. 

b.  Provide  an  option  for  grid  display  and  snap-to  object. 

c.  Finish  implementation  of  undo/redo  feature. 

d.  Provide  measurement  features  between  two  locations. 

3.9. 2. 6  Automating  the  Integration  of  Savage  Studio  with  the  Savage  Library 
Yumetech  has  identified  the  improved  integration  of  Savage  Studio  with  the 
Savage  X3D  Archives  as  a  key  component  of  this  phase  of  the  project.  This  integration  will 
facilitate  the  rapid  deployment  of  new  models  and  behaviors  into  the  authoring  tool,  and  will 
significantly  improve  the  utility  of  this  tool.  An  important  task  in  this  component  is 
Savage/Savage  Defense  Automation;  that  is  the  automation  of  some  tasks  involved  in 
maintaining  Savage  and  Savage  Defense  libraries.  These  tasks  include: 

a.  Create  a  SMAL  size  checker  to  insure  3D  models  match  simulation  data. 

b.  Multi-URL/fallback  fill-in — fill-in  URL  fields  with  local  and  web  fallbacks 
for  URLs. 

c.  Auto-generate  top-down  map  view  from  the  actual  3D  model  of  the 
location. 

d.  Auto-generate  icons  for  Savage  entities. 
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3.9.2. 7  Day/Night/Weather  Effects 

The  current  system  assumes  clear  weather  in  daytime  conditions.  Simulations 
would  be  greatly  enhanced  by  implementing  visual  and  simulation  changes  for  difference  in 
sensor  performance  in  different  conditions. 

3.9.3  Yumetech,  Inc.  Team 

Alan  Hudson,  President  and  CEO 

Justin  Couch,  Software  Engineer 
Stephan  Matsuba,  CFO 
http://www.yumetech.com 

http://www.xi3d.org 
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4.0  SUMMARY  AND  CONCLUSIONS 


4.1  M&S  WORKSHOP  CONCLUSIONS  FROM  (BRUTZMAN  ET  AL.  2006) 

The  primary  intended  outcome  of  the  workshop  was  simply  informed  discussion  of 
current  Research  and  Development  (R&D)  projects.  A  secondary  goal  is  continued  broad 
sharing  and  promulgation  of  relevant  technical  information.  Consensus  of  the  attendees 
indicated  that  both  goals  were  well  achieved.  There  was  also  strong  demand  to  conduct  follow- 
on  meetings  to  solidify  the  information  exchange  and  opportunities  for  technical  collaboration 
that  were  evident  in  the  meetings.  Presentations  and  demonstrations  clearly  showed  that  many 
tools  had  overlapping  capabilities... 

This  event  may  have  been  the  first  time  that  a  group  of  M&S  practitioners  performing 
related  efforts  in  naval  installation  security  have  been  brought  together.  This  is  a  good  start,  and 
such  efforts  need  to  continue...  Workshop  participants  saw  a  broad  set  of  activities  presented  and 
demonstrated,  cutting  across  a  variety  of  exercises  involving  human  participants,  automated 
analysis,  and  real-world  decision  support.  Common  to  all  was  importance  of  correlated  2D  and 
3D  visualizations,  representations  of  facilities  and  bases,  modeling  of  sensors  and  environmental 
conditions,  computing  measures  of  interest,  and  modeling  other  aspects  of  the  problem.  Despite 
significant  challenges,  there  are  large  opportunities  for  sharing  of  resources  if  practitioners  are 
able  to  adopt  specific  standards  and  establish  community  contributions  for  interchange  and  reuse. 
Otherwise,  massive  overlap  of  human  and  monetary  capital  in  duplicative  efforts  is  likely  to 
prevent  ever-limited  resources  from  establishing  the  more  sophisticated  models  that  are  needed 
to  solve  complex  real-world  problems. 

Specific  conclusions  gleaned  from  the  Workshop  include: 

•  The  Workshop  was  exceptionally  important  and  provided  great  value  to  the 
attendees. 

•  Free  technical  interchange  without  specific  programmatic  constraints  allowed  better 
exploration  of  potential  technical  capabilities. 

•  One  or  more  sponsors  with  direct  interest  in  these  activities  ought  to  participate  to 
ensure  continued  progress. 
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•  Further  CNI  and  NAVFAC  participation  would  be  valuable. 

Based  on  the  clear  group  consensus  which  produced  the  workshop  findings,  we 
recommend  the  following  actions  be  taken: 

•  Propose  a  special  issue  on  Installation  Security  for  the  Journal  of  Homeland  Security 
Affairs. 

•  Participants  should  consider  attending  the  NPS  MOVES  Institute  Open  House 
tutorial  session  August  7,  2006,  including  project  presentations  and  demonstrations 
during  the  Open  House  August  8-10. 

•  Establish  the  necessary  organization  to  enable  some  form  of  working  group  to 
continue  to  address  the  issues  raised  in  this  Workshop. 

•  Plan  a  follow-on  meeting  to  be  held  in  4-6  months. 

•  Candidate  sponsors  are  requested  to  review  this  report,  talk  to  participants  and 
consider  establishing  a  partnered  activity  by  multiple  sponsors  in  order  to  continue 
workshop  efforts  and  technical  collaboration. 

•  Various  parties  who  have  modeled  certain  ports  ought  to  compare  collected  assets, 
evaluate  what  resources  exist  and  determine  how  those  resources  might  be  best 
merged  for  broader  use. 


4.2  PHASE  II  CONCLUSIONS  AND  RECOMMENDATIONS 

The  reader  is  referred  to  the  previous  chapter  (see  Chapter  3)  for  detailed  sub-contractor 
and  partner  conclusions  extracted  from  their  summary  reports.  The  editors  of  this  technical 
report  feel  that  these  are  sufficient  for  the  purposes  of  this  report. 
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APPENDIX  A.  NAVAL  INSTALLATION  SECURITY  MODELING  AND 

SIMULATION  WORKSHOP 


ATTENDEE  LIST: 


LT  Charles  Adams 

USS  Bonhamme  Richard 

MAJ  Darryl  Ahner 

US  Army  TRADOC  Analysis  Center,  Monterey 

Dan  Ancona 

Planet  9  Studios 

Michael  Ayling 

Commander,  Navy  Installations  Command 

Doug  Backes 

US  Pacific  Fleet 

Margaret  Bailey 

Sonalysts,  Inc. 

Manoj  Bhardwaj 

Sandia  Laboratories 

Curtis  Blais 

NPS  MOVES 

Joyce  Borgen 

Center  for  Asymmetric  Warfare 

Platt  Brabner 

21st  Century  Systems,  Inc. 

Don  Brutzman 

Naval  Postgraduate  School  MOVES  Institute 

Chris  Carlson 

Metron  Corporation 

David  Colleen 

Planet  9  Studios 

Jeff  Debrine 

OPNAV  N81 

Alexandra  Devisser 

Naval  Facilities  Engineering  Service  Center 

Ayman  El-Swaify 

Naval  Facilities  Engineering  Command,  Naval  Information 
Technology  Center 

David  Garvey 

Boeing  Phantom  Works 

Dennis  Garrood 

Sound  &  Sea  Technologies 

Rick  Goldberg 

Aniviza 

Riley  Goodin 

Northrop  Grumman  Corporation 

Chris  Greuel 

Planet  9  Studios 

Christopher  Guryan 

ARES  Corporation 

Sean  Harrigan 

MOVES  Institute 

Alan  Hudson 

Yumetech 

CDR  John  Inman 

US  Pacific  Fleet 

Ray  Jakobovits 

Metron  Corporation 

Dustin  Kozal 

21st  Century  Systems,  Inc. 

Steve  Kunkle 

ARES  Corporation 

J.  D.  Miller 

Johns  Hopkins  University  Applied  Physics  Laboratory 

Elizabeth  Morin 

Booz-Allen 

Terry  Norbraten 

NPS  MOVES 

Robert  Seligman 

SAIC 

LT  Pat  Sullivan 

NPS  MOVES 

Pete  Swan 

MaK  Technologies 

Doris  Tumage 

US  Army  Engineer  Research  and  Development  Center 

Jeffrey  Weekley 

NPS  MOVES 

Doug  Weihnacht 

Kinection 

David  Zeltzer 

Northrop  Grumman  Corporation 
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NAVAL  INSTALLATION  SECURITY  MODELING  AND  SIMULATION  WORKSHOP 
AGENDA: 


Workshop  Day  1:  May  9,  2006  Tuesday 


0800  Registration 

0830  Welcome  to  Monterey  &  NPS  -  Don  Brutzman,  NPS  Principal  Investigator 

Workshop  Objectives  -  Don  Brutzman,  NPS  Principal  Investigator 

NPS  Presentation  and  Demonstrations:  3D  Modeling  Applied  to  the  AT/FP 
Problem  and  Interfacing  to  the  Simulation  for  Data  Mining  -  Don  Brutzman 
and  NPS  Savage  Team 

1000  Break  (Set  up  of  NPS  Wireless  Guest  Accounts) 

1030  Invited  Presentation:  M8iS  Applied  to  AT/FP  Harbor  Defense  Measures  of 
Effectiveness  and  Measures  of  Performance 

-  Chris  Carlson  and  Ray  Jakobovits,  Metron  Corporation 

1130  Lunch 

1300  Invited  Presentation:  Application  of  the  AVERT  Model 

-  Christopher  Guryan  and  Steve  Kunkle,  ARES  Corporation 

1400  Invited  Presentation:  Application  of  Simulation  to  Large-Scale  Exercises 

-  Joyce  Borgen,  Center  for  Asymmetric  Warfare 

1430  Break 

1500  Inserted  Presentation:  Graduate  Education  for  Homeland  Defense  and 
Security  -  Dr.  Paul  Stockton,  NPS  Director,  Center  for  Homeland  Defense 

1515  Invited  Presentation:  Using  M&S  Tools  to  Simulate  Terrorist  Attacks 

-  Doris  Turnage,  US  Army  Engineer  Research  and  Development  Center  (ERDC),  and 
MAJ  Darryl  Ahner,  TRAC-Monterey 

1 630  Open  Source  and  Open  Standards  for  Long-term  Project  Success:  Lessons 
from  3D  Model  Management 

-  Don  Brutzman,  NPS  Principal  Investigator 

1700  Workshop  Day  1  Summary  and  Wrap-up 

-  Don  Brutzman,  NPS  Principal  Investigator 

1800  Social  Hour  and  Dinner  (Hula's  in  Monterey) 
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Workshop  Day  2:  May  10,  2006  Wednesday 


0800  Session  2  Agenda  and  Objectives 

-  Don  Brutzman,  NPS  Principal  Investigator 

0815  Invited  Presentation:  Physics  Based  Modeling  and  AT/FP  Ashore  M8iS  - 

Margaret  Bailey,  Sonalysts 

0900  Invited  Presentation:  3D  Geospatial  Data  Interfaces  and  Tools 

-David  Colleen,  Planet  9  Studios 

1000  Break 

1030  Invited  Presentation:  Shipboard  Area  Protection  Systems 

-  Platt  Brabner,  21st  Century  Systems,  Inc. 

1100  Invited  Presentation:  "GJS  Central"  NAVFAC's  Approach  to  Centrally  Hosting 
and  Delivering  the  Navy's  GeoReadiness  Repository  -  Ayman  El-Swaify,  Naval 
Facilities  Command,  Naval  Information  Technology  Center  (NAVFAC  NITC)  (via 
conference  call) 

1200  Lunch 

1330  Invited  Presentation:  Open  Source  Discrete  Event  "Extend"  and 
Open  Source,  System  Dynamics  "Vensim"  Efforts 

-  David  Garvey,  Boeing 

1400  Survey  of  Additional  Naval  Installation  Security  Related  Modeling  and 
Simulation  Efforts 

-  Dennis  Garrood,  Sound  and  Sea  Technologies  (S&ST) 

1500  Break 

1530  Invited  Presentation:  Tactical  Decision-Making  Training  for  Force  Protection 

-  Pete  Swan,  MaK  Technologies 

1630  Workshop  Critique  and  Go-Forward  Discussion  -  Don  Brutzman,  NPS  Principal 
Investigator  (Moderator) 

1730  Workshop  Day  2  and  Public  Attendee  Session  Concludes:  Social  Hour,  NPS 
Trident  Room  (Basement  of  Herrmann  Hall) 


Workshop  Day  3:  May  11,  2006  Thursday  (organizers  only) 


0700  Assemble  report  of  Workshop  presentations,  findings  and  recommendations 
1700  Workshop  Complete 
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APPENDIX  B.  INSTALLATION/OPERATION  TUTORIAL  AT  NPS 
MOVES  OPEN  HOUSE,  AUGUST  7,  2006 


AT/FP 


August  7-8,  2006  Tutorial  Announcement: 
NPS  Waterside  Security  (WSS) 
Anti-Terrorism  /  Force  Protection  (AT/FP) 
Analysis  Tool 


r/THE  MOVES  INSTITUTE 


NAVAL  POSTGRADUATE  SCHOOL 


Introduction:  How  can  we  plan  for  the  defense  of  our  nation’s  harbors  and  waterways  in  a  way  that  shows  us 
surprise  scenarios  that  we  never  imagined?  How  do  we  graphically  visualize  the  tactical  execution  of  our  force- 
protection  plans?  How  do  we  compute  statistical  data  to  support  findings  of  best-effort  plans  for  our  naval  forces 
afloat?  How  do  we  use  Java  to  model  opponents,  render  entire  harbors  using  interactive  3D  graphics,  and  even  run 
grid  clusters  to  provide  high-confidence  analytic  results?  This  tutorial  shows  how. 

Eligibility:  The  tool  and  the  instruction  are  open  to  all,  but  there  will  be  a  US  Government  only  (For  Official  Use 
Only)  session  during  the  tutorial  that  will  be  closed  to  foreign  attendees. 

Location:  The  tutorial  will  be  conducted  in  the  Mechanical  Engineering  Auditorium,  just  outside  the  main  doors  to 
Watkins  Hall,  at  the  Naval  Postgraduate  School  (NPS),  Monterey,  California. 

Dates:  The  tutorial  will  run  from  9am  Monday  August  7  through  1  lam  Tuesday  August  8  preceding  the  start  of  the 
Modeling,  Virtual  Environments,  and  Simulation  (MOVES)  Institute  Open  House. 

Registration:  To  attend  the  tutorial,  register  for  the  MOVES  Open  House,  scheduled  for  August  8-10,  2006  at  the 
Naval  Postgraduate  School,  Monterey,  California. 

Online  registration:  http://gallerv.bcentral.com/GID5061928DD447447-Conferences.aspx 

Maps  and  other  information  are  available  on  the  MOVES  Institute  web  site:  http://www.nps.navy.mil/moves/ 

Please  RSVP  your  intention  to  attend  this  tutorial  by  sending  e-mail  to  Terry  Norbraten,  MOVES  Institute: 

tdnorbra@nps.edu 

Tutorial  Schedule 

Tutorial  Day  1:  August  7,  2006  Monday ,  0900-1700 
0900  Project  Overview:  Associate  Professor  Don  Brutzman 

0930  Introduction  to  Harbor  Modeling  and  Simulation  using  Agent-Based  Tactics  and 
Discrete  Event  Simulation  (DES):  LT Pat  Sullivan 
1030  Break 

1045  Security-Assessment  Demonstration  for  Bremerton  &  Pearl  Harbor:  LT  Pat  Sullivan 
1230  Lunch 

1330  Behavior  Modeling  using  Viskit  Event  and  Assembly  Graphs:  Dan  Ancona 
1415  2D/3D  Scenario  Generation  using  SavageStudio:  Alan  Hudson 
1500  Break 

1515  Building  Geo-Registered  X3D;  Port  &  Harbor  Models  Accurately  Located: 

Christian  Greuel,  Planet  9  Studios 
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1545  Design  of  Experiments  (DOE)  and  Cluster  Operations:  Rick  Goldberg 
1615  Break 

1630  Summary,  Group  Discussion,  Conclusions  and  Next  Steps:  Don  Brutzman 

Tutorial  Day  2:  August  8,  2006  Tuesday,  0900-1200 

Hands-on  Scenario  Analysis  Session,  O&A:  to  be  held  in  the  Ingersoll  Building  Room 
366  (ING  366) 
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APPENDIX  C.  AT/FP  PROJECT  FLYER 


NPS  Waterside  Security  (WSS)  Anti-Terrorism  /  Force  Protection  (AT/FP)  Project 


How  can  we  plan  for  the  defense  of  our  nation’s  harbors  and  waterways  in  a  way  that  shows  us  surprise  scenarios 
that  we  never  imagined?  How  do  we  graphically  visualize  the  tactical  execution  of  our  force-protection  plans? 
How  do  we  compute  statistical  data  to  support  findings  of  best-effort  plans  for  our  naval  forces  afloat?  How  do  we 
use  Java  to  model  opponents,  render  entire  harbors  using  interactive  3D  graphics,  and  even  run  grid  clusters  to 
provide  high-confidence  analytic  results?  This  project  shows  how. 


The  NPS  waterside  security  project  is  a  group  effort.  A  top-notch  team  of  government,  industry  and  academic 
experts  is  using  Java  to  produce  a  tactical  application  for  use  in  defending  national  harbors  and  waterways. 
Scenarios  can  be  autogenerated,  viewed,  analyzed,  and  manipulated  by  end  users.  Individual  scenarios  can  be 
replayed  from  any  vantage  point  using  agent-driven  X3D  graphics  models.  Cluster-based  computational  assets  use 
the  Sun  Grid  Engine  for  massive  replication  of  heavy-duty  simulation  scenarios,  producing  measures  of 
effectiveness  within  statistically  significant,  analyst-specified  confidence  intervals. 

Key  technical  features  include: 

•  End-to-end  open-source  Java  application,  using  Extensible  Markup  Language  (XML)  for  all  datasets 

•  ISO-Standard  Extensible  3D  Graphics  (X3D)  scenes  using  military  model  archives 

•  Xj3D  open-source  browser  built  with  Java  for  OpenGL  (JOGL)  rendering  speed 

•  Web-services  queries  for  environmental  forecasts  and  oceanographic-dataset  updates 

•  Runs  out-of-the-box  on  Windows,  Linux,  Mac  OS  X,  Solaris  SPARC,  Solaris  x86  operating  systems, 
with  NO  Java  recoding  or  X3D  model  adjustment  required  to  achieve  consistent  operation  throughout 


In  order  to  model  realistic  battle  tactics  for  friendly  forces  and  opponents,  the 
waterside  security  project  uses  Viskit  and  Simkit,  open-source  Java  2™  packages 
built  for  visual  creation  of  Discrete  Event  Simulation  (DES)  models.  Simkit  is  used 
at  NPS  to  make  advanced  simulation  capabilities  available  to  analysts, 
demonstrating  meaningful  real-world  results.  Simkit  labs  and  tutorials  are  available 
online,  downloadable  at  https://diana.cs.nps.navy.mil/Simkit. 
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NAVMSMO 


Navy  Modeling  and  Simulation  Management  Office 


n 

1  planet  5^ 

J  L 

studios 

This  work  was  publicly  demonstrated  27  July  2005  as  part  of  the  Sun  Microsystems  JavaONE  conference  keynote 
session  in  San  Francisco  California.  Seven  thousand  attendees  in  Moscone  Center  plus  250,000  remote  attendees 
watching  the  webcast  saw  this  agent-based  3D  simulation  running  in  real  time. 

900,000  lines  of  Java  library  code  ran  on  a  new  Java  Ultra  20  Solaris  PC  with  exceptional  performance. 

Viewable  online  at  http://iava.sun.com/iavaone/sf/2005  (view  Webcasts,  Day  One,  minute  1:23) 

The  production  team  putting  all  this  work  together  includes  the  following  Web3D  Consortium  partners: 

•  NPS  MOVES  Institute,  Dr.  Don  Brutzman,  http://www.MovesInstitute.org  MOVES  is  currently  partnering 
as  a  Sun  Center-of-Excellence  (COE)  in  Modeling  and  Simulation 

•  Planet  9  Studios,  David  Colleen,  CEO,  http://www.planet9.com 

•  Yumetech,  Inc.,  Alan  Hudson,  CEO,  http://www.yumetech.com 

•  Aniviza,  Inc.,  Rick  Goldberg,  CEO,  http://www.aniviza.com 

Sponsors  include: 

•  Naval  Facilities  Engineering  Service  Center  (NFESC),  https://portal.navfac.navy.mil 

•  Navy  Modeling  &  Simulation  Office  (NMSO),  http://nmso.navv.mil 

•  Web3D  Consortium,  http://www.web3D.org 


Network  connectivity  is  provided  among  multiple  users  via  standards-based  implementation  of  the  IEEE  Distributed 
Interactive  Simulation  (DIS)  behavior  protocol.  This  waterside  security  project  will  soon  undergo  initial  user  testing 
using  naval  officers  at  NPS,  and  then  be  tested  using  actual  waterfront  facilities.  It  is  likely  to  provide  significant 
improvements  in  the  situational  awareness  and  defensive  posture  of  ships  defending  against  terrorist  attacks  in  port. 
The  demonstrated  scenario  features  friendly  security  forces  defending  against  hostile  entities  in  a  simulated  attack 
on  Bremerton  Washington  harbor. 
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AT/FP 


May  2006  Project  Update: 
Modeling  Pearl  Harbor  Waterfront 


rTHE  MOVES  INSTITUTE 


NAVAL  POSTGRADUATE  SCHOOL 


The  NPS  waterside-security  team  is  currently  demonstrating  an  updated  set  of  software  tools  for  modeling, 
simulation,  visualization  and  analysis  of  harbor  defense.  Current  capabilities  are  being  tested  using  Extensible  3D 
(X3D)  graphics  models  for  Bremerton  harbor,  the  ABOT  Iraqi  oil  terminal  and  the  Indian  Island  logistics  pier.  Pearl 
Harbor  modeling  is  in  progress.  A  tutorial  course  is  simultaneously  being  developed  in  order  to  rapidly  expose  the 
combined  efforts  of  20  government  and  industry  experts. 

Three  customers  are  envisioned  for  this  integrated  suite  of  analytic  tools. 

•  Port  security  investment :  how  to  best  invest  harbor-defense  funds  to  maximize  defense  against  risks 

•  Port  operations:  how  to  best  deploy  current  assets  on  the  water  now  for  maximum  defensive  posture 

•  Ship  +  harbor  coordination:  help  ships  train  sailors  to  be  immediately  effective  upon  entering  port 

This  is  an  alpha-stage  software  release,  being  shown  as  a  proof-of-concept  tutorial  to  gain  professional  feedback. 
This  work  is  also  being  demonstrated  as  part  of  an  invitation-only  industry  workshop  on  modeling  &  simulation 
capabilities,  hosted  at  NPS  in  Monterey  California,  8-10  May  2006.  All  software  and  content  models  are  being 
produced  as  open  source.  Use  of  open  standards  and  unencumbered  business-friendly  licenses  that  protect 
government  rights  is  expected  to  maximize  potential  growth  and  interoperability.  Current  work  remains  unclassified 
with  access  restrictions  designated  For  Official  Use  Only  (FOUO).  Initial  release  is  scheduled  for  10  August  2006 
at  the  NPS  MOVES  Open  House.  https://www.MovesInstitute.org 

Risk  models  are  connected  and  run  in  a  complex  adaptive  multi-agent  system.  Simulations  are  either  visualized 
“live”  in  real  time  on  the  desktop,  or  massively  replicated  for  statistical  analysis  using  low-cost  computer  clusters. 
Such  Monte  Carlo  repetition  lets  analysts  confidently  determine  whether  defensive  improvements  are  truly  effective, 
using  either  commodity  computers  or  high-performance  computing  assets. 

In  addition  to  tool  development,  the  group  is  modeling  the  Pearl  Harbor  waterfront  for  in-depth  risk  analysis.  The 
next  major  milestone  will  support  automatic  creation  of  detailed  analyst-annotated  risk-analysis  reports. 


A  Navy  Lieutenant  master’s  student 
from  NPS  and  a  professional 
photographer  from  Planet  9  Studios 
were  given  official  port  access  to  Navy 
facilities  in  Pearl  Harbor,  shooting  2,700 
photographs  in  4  days.  These  are  being 
assembled  into  a  high-fidelity  X3D 
model  of  the  Navy-controlled  port. 


This  real-world  study  evaluating  Pearl 
Harbor  is  the  first  large-scale  test  of  this 
application  and  research.  Results  are 
being  geared  to  support  analysts 
responsible  for  port  security. 


This  approach  is  repeatable  for  other 
ports  and  harbors,  adding  a  tool-based 
suite  of  new  capabilities  to  homeland 
defenders. 
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The  new  Savage  Studio  authoring  tool  supports  scenario  creation  with 
2D/3D  “pick  and  place”  functionality.  In  other  words,  users  can  lay 
down  a  harbor-defense  scenario  by  selecting  ship  assets  from  a  menu, 
then  drag  and  rotate  ship  icons  into  position.  Simulations  are  then  ready 
to  start. 

The  just-published  Savage  Modeling  and  Analysis  Language  (SMAL)  is 
used  to  embed  well-defined  metadata  annotation  capabilities  within  each 
model,  suitable  for  further  tool  exposure  using  the  Extensible  Markup 
Language  (XML). 

Thus  models  “know  what  they  are”  and  analysts  merely  need  to 
customize  capabilities  to  match  the  current  scenario. 

Use  of  ISO-standard  X3D  graphics  means  that  the  growing  ship-model 
library  can  remain  royalty  free,  open  source,  broadly  interoperable,  and 
approved  for  Navy  use. 


A  lv.nl  Gi.pl>  Inpwl.i 


“Intelligent”  adversaries  are  modeled  using  an 
intuitive  flowchart-style  tool  that  lays  out  tactics 
for  “good  guy”  and  “bad  guy”  behaviors  using 
terms  similar  to  those  used  by  actual  warfighters. 

Libraries  of  tactical  agent-based  behaviors  are 
being  developed  by  active-duty  Naval  officers. 
Scenario  creation  and  design  of  experiments  for 
new  ships  and  ports  is  thus  simple  and 
repeatable. 

Terrorist  models  can  also  improve  tactics  and 
their  probability  of  success  over  replications, 
exposing  potential  areas  of  vulnerability. 
Simulation  insights  thus  enable  analysts  to 
recommend  prioritized  harbor  improvements. 


The  ability  to  accurately  reproduce 
simulated  and  actual  scenarios  is 
expected  to  increase  user  confidence 
that  the  tool  provides  satisfactory  and 
dependable  analysis  results. 

Navy  and  Coast  Guard  sailors  can 
further  use  X3D  playback  to  visualize 
their  own  roles  in  harbor  defense  (and 
even  points  of  view  for  potential 
adversaries)  as  scenarios  progress. 

Project  partners  are  documenting  the 
process  and  software  tools,  allowing  for 
repeatable  approaches  for  all  future 
work  and  easier  integration  by 
engineering  and  fleet  users. 


Inquiries  are  welcome.  For  further  info,  contact  Don  Brutzman  (brutzman@nps.navv.mil).  1.831.656.2149. 
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APPENDIX  D.  MODELING  AND  SIMULATION  WORKSHOP  CD-ROM 


U.S.  Government  agencies  and  their  Contractors  may  obtain  a  copy  of  the  Workshop  CD 
via  request  to  the  NPS  MOVES  Institute. 
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APPENDIX  E.  DISKIT  SENSOR  AND  MOVER  DYNAMICS: 
LOGARITHMICALLY  RANGED  ATTENUATED  TRANSMISSION  LOSS 

SONAR 


by 

Rick  Goldberg,  Aniviza  Inc. 


This  document  is  intended  to  serve  as  background  reading  for  implementers  of  Diskit  Sensors,  along  with  example  material  to 
demonstrate  application  of  physically  based  models  with  Diskit,  Viskit  and  Simkit 
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E.l  DISKIT  SENSOR  AND  MOVER  DYNAMICS 


E.1.1  Overview 

Diskit  provides  a  set  of  base  classes  for  defining  3D  Simkit 1  Discrete  Event  Simulations 
(DES).  This  includes  definitions  for  3D  entities,  collision  and  sensor  detection,  weapons,  target 
and  munition  adjudication,  scenario  management,  and  DIS  protocol  communications.  Diskit  is 
mostly  based  on  2D  Simkit  classes  for  the  same,  either  directly  by  subclassing  where  possible, 
or  in  some  cases  by  evolving  Simkit  utility  classes,  with  some  added  features  to  enable 
networking  and  more  rapid  prototyping  using  Viskit.  Diskit  is  part  of  the  Viskit  visual  editor  for 
Simkit  distribution. 

Viskit  Graphical  User  Interface  (GUI) 


Figure  5.  Simkit,  Viskit,  Diskit  Platform  Relationships 


On  top  of  Diskit's  own  base  entity  classes,  sample  classes  for  simulation  of  derivative 
behavior  types  such  as  patrol  craft,  bridge  communications,  neutrals,  and  terrorists  are  included. 


1  Simkit:  see  home  page,  http://diana.gl.nps.navy.mil/Simkit/ 
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E.1.2  DISMover3D 


The  DISMover3D  entity  shown  below  listens  for  and  generates  a  number  of  events  that 
determine  the  3D  position  and  velocity  for  the  point  center  of  a  moving  object  in  space.  More 
complex  behaviors  are  based  upon  interposing  filters,  either  by  listening  for  these  events  or  upon 
monitoring  changes  to  the  underlying  state  variables. 


Figure  6.  DISMover3D  Entity  in  Event  Graph  Form 
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The  base  DISMover3D  and  all  subclasses  take  at  minimum  the  following  parameter  map 


Event  graph  parameters 

Double  click  a  row  to 

name  type 

description 

1  originalStartPosition  diskit. Vec3d 

Must  be  anything  but  the  first  waypoint. 

maxSpeed  double 

moverlD  int 

+  - 

Figure  7.  DISMover3D  Parameters 

Events  ultimately  cause  some  state  to  become  altered.  State  variables  for  the 
DISMover3D  cover  speed,  direction,  start  position,  destination,  movement  type,  and  time  of 
movement. 


State  Variables 
Double  click  a  mw  to 

name 

type 

description 

velocity 

diskit.  Vec3d 

destination 

diskit.  Vec3d 

duration 

double 

ImovementState 

simkit .  smdx .  Mo  vementState 

startPosition 

diskit.  Vec3d 

lastVelocity 

diskit.  Vec3d 

deltaTime 

double 

last  checked  time  at  start ... 

IcruisingSpeed 

double 

cruise  speed 

+  - 

Figure  8.  State  Variables  for  the  DISMover3D  Entity 


In  the  Event-Graph  diagram  above,  in  most  cases  it  is  sufficient  to  send  a  StartMove 
event  to  cause  motion  for  the  DISMoverSD ,  which  can  also  be  reached  by  way  of  the 
NextWaypoint  event.  The  NextWaypoint  event  itself  is  loaded  with  a  diskit.  Vec3d  (Vector  3D)  as 
the  position  value  for  the  actual  waypoint  to  go  to  next,  as  well  as  a  double-precision  valued 
cruiseSpeed  for  how  fast  to  get  there.  Once  sent  and  received,  this  event  causes  calculation  of 
updated  velocity  information  for  the  entity. 

This  eventually  leads  to  the  fundamental  question,  how  is  time  represented  and  managed 
in  a  simulation?  For  the  DISMover3D,  time  is  a  variable  that  can  proceed  in  discrete  arbitrary 
increments.  It  doesn't  require  passage  of  time  duration  in  the  real  sense  as  it  is  just  a  calculation; 
when  run,  no  more  real  time  is  needed  to  go  from  point  A  to  B  whether  the  distance  great  and 
speed  small,  or  the  other  way  around.  This  is  great  for  analysis,  for  example,  one  would  not  want 
to  wait  a  year  to  study  a  simulated  year.  For  visualization  and  for  DIS  communication  however, 
real  time  must  be  injected  into  the  simulation  run  at  regular  intervals  independently  of  all  other 
operations. 

This  is  accomplished  by  way  of  Diskit’s  DISTimer  (formerly  DISPinger).  The  DISTimer 
calculates  the  ratio  of  a  given  simulation  time  unit  to  real  time  delay,  and  causes  the  entire 
simulation  to  simply  wait  and  pause  the  simulation  thread  of  execution  for  the  desired  interval  of 
real  time,  wake  up  long  enough  to  send  DIS  network  communication  packets  updating  DIS 
listeners  with  current  positions  for  all  registered  movers,  fire  any  pending  events,  and  go  back  to 
sleep  for  the  next  round.  More  about  how  entities  are  registered  is  outlined  in  section  4,  Scenario 
Manager. 


E.1.3  Sensors,  Targets  and  Mediators 

Diskit  uses  Simkit's  base  Sensor  and  Target  Mediator  architecture  to  schedule  various 
type  detection  events  in  the  queue  stream.  A  Sensor  generally  consumes  some  volume  of  space 
and  is  located  by  the  position  of  a  DISMover3D  that  owns  it.  Conceptually,  whenever  any  of  the 
registered  Targets  changes  velocity  vector  states,  a  calculation  is  done  for  each  Sensor  and 
Target  to  solve  for  any  pending  penetration  and  exit  points,  at  some  time  in  “the  future”  of  the 
event  queue,  and  at  once  canceling  any  such  already-pending  events  that  become  invalid,  thereby 
removing  them  from  the  queue.  This  is  in  contrast  to  fixed-timestep  frame-by-frame  collision 
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detection  architectures,  and  allows  for  more  complex  behavior  systems  such  as  planned  obstacle 
avoidance,  for  example. 


Figure  9.  Diagram  of  Cancelling  Invalid  Pending  Events  Due  to  Change  in  Target  Velocity  Vector 

State 

The  base  classes  provided  by  Diskit  that  implement  the  Sensor  interfaces  are  simplified 
moving  sphere  and  ray  intersections.  However  the  architecture  is  intended  to  be  extendable  in 
such  a  way  as  to  enable  more  complex  detection  algorithms  and  geometries.  Once  a  Target 
enters  or  exits  the  range  of  a  Sensor  for  instance,  there  may  be  additional  logic  to  describe 
whether  or  not  the  mere  EnterRange  event  is  sufficient  to  cause  a  Detection ,  whereas  the  default 
SphereCutterSensor  is  always  true  for  EnterRange.  An  alternate  Sensor  type  can  be  registered 
with  the  ScenarioManager  that  may  or  may  not  schedule  a  Detection  based  upon  probability 
parameters,  or  as  well  may  check  some  other  geometry. 

The  default  intersection  test  for  SphereCutterSensor  only  takes  into  account  the  point-ray 
intersection  of  a  DISMover3D's  velocity  vector  versus  the  moving  sphere  boundary  of  a  sensor, 
and  does  not  factor  in  the  DISMover3D's  own  geometric  bounds.  By  default,  the  DISMover3D 
has  zero  spatial  bounds.  Subclasses  of  course  do  usually  know  about  their  dimensions,  and  more 
advanced  applications  are  required  to  specify  higher  fidelity  models.  But  how  is  this 
accomplished? 
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First  let's  examine  the  algorithmic  representation  of  simplified  intersection  math  given  by 
Diskit's  Intersector3D  class. 


1  /* 

2  *  Intersector3D. java 

3  * 

4  *  Created  on  November  18,  2004,  11:17  AM 

5  *  @author:  Rick  Goldberg 

6  */ 

7 

8  package  diskit; 

9 


10  public  class  Intersector3D  { 


11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 
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private  Intersector3D ()  { 

} 

/**  Solve  moving  sphere  initersection  */ 

public  static  double []  solve (  Vec3d  sensorLocation,  Vec3d  sensorVelocity, 
double  sensorRange,  Vec3d  targetLocation,  Vec3d  targetVelocity  )  { 

double  px,  py,  pz,  qx,  qy,  qz,  vx,  vy,  vz,  ux,  uy,  uz; 
doublet]  times  =  new  double [2]; 

//System. out .print ( "targetLocation  :") ; 

//targetLocation. print () ; 

/*  Let  P  =  target  position  */ 
px  =  targetLocation. get (0) ; 
py  =  targetLocation. get (1) ; 
pz  =  targetLocation. get (2) ; 

//System. out .print ("sensorLocation  : ; 

//sensorLocation. print () ; 

/*  Let  Q  =  sensor  position  */ 
qx  =  sensorLocation. get (0)  ; 
qy  =  sensorLocation. get (1) ; 
qz  =  sensorLocation. get (2) ; 

//System. out .print ("targetVelocity  :") ; 

//targetVelocity .print () ; 

/*  Let  V  =  target  velocity  */ 
vx  =  targetVelocity . get (0) ; 
vy  =  targetVelocity . get (1) ; 
vz  =  targetVelocity . get (2) ; 

//System. out .print ( "sensorVelocity  :") ; 

//sensorVelocity .print ( ) ; 

/*  Let  U  =  sensor  velocity  */ 
ux  =  sensorVelocity . get (0) ; 
uy  =  sensorVelocity . get (1) ; 
uz  =  sensorVelocity . get (2) ; 

//System. out .println ("sensorRange  : "+sensorRange) ; 

/*  Solve  the  intersection  of  the  ray  from  P  through  a  sphere  about  Q  */ 
/*  First  xA2  +  yA2  +  zA2  =  RA2  ,  but  in  cartesean  coordinates,  Q  is  */ 
/*  also  moving.  Transformation  of  the  coordinates  to  Q's  own  space  */ 
/*  can  be  simplified  since  there  is  no  scale  or  rotation  or  skew  or  */ 
/*  perspective,  then  Q  is  not  moving  and  the  values  can  be  solved  for*/ 
/*  t  by  the  quadratic  equation,  giving  relative  entry  and  exit  times.*/ 

/*  Step  1.  Transform  V  to  Q's  coordinate  system  */ 
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66  vx  -=  ux; 

67  vy  -=  uy; 

68  vz  -=  uz; 

69 

70  /*  Step  2.  Transofrom  P  to  Q's  coordinate  system  */ 

71 

72  px  -=  qx; 

py  -=  qy; 

74  pz  -=  qz; 

75 


76 

//System. out .println ("px :  "+px+"  py:  " 

+py+"  pz:  ”+pz) ; 

77 

//System. out. println ("vx:  "+vx+"  vy:  " 

+vy+"  vz :  "+vz) ; 

78 

79 

/* 

For  the  point  S  in  Q  space  now 

represented  by  P, 

parametrically  is 

*/ 

80 

/* 

Vt  +  P  =  S (t)  ,  note  V  is  also 

now  in  Q  space  but  in  practice  save 

* 

81 

/* 

some  runtime  memory  by  reusing 

the  variables  but 

keeping  the  name . 

*/ 

82 

/* 

eg: 

83 

/* 

x(t)  =  (vx  *  t)  +  px; 

84 

/* 

y(t)  =  (vy  *  t)  +  py; 

85 

/* 

z (t)  =  (vz  *  t)  +  pz; 

*/ 

86 

/* 

then  xA2  +  yAz  +  zA2  =  rA2 

87  *  expanding  out,  we  see  that  we  get  something  of  the  form 

88  *  AtA2  +  Bt  +  C  =  0  and  solve  quadratically  for  timeO  and  timel  */ 

89 

90 

91  double  a  =  (vx*vx  +  vy*vy  +  vz*vz) ; 

92  double  b  =  (2* (vx*px+vy*py+vz*pz) ) ; 

93  double  c  =  (px*px  +  py*py  +  pz*pz)  -  sensorRange*sensorRange; 

94 

95  //System. out .println ("a:  "+a+"  b:  "+b+"  c:  "+c) ; 

96 

97  double  root  =  Math. sqrt (b*b  -  4*a*c) ; 

98 

99  //System. out .println (  "bA2  -  4ac  +  (b*b  -  4*a*c)); 

100  //System. out .println (  "root  +  root); 

101 

102  if  (  root  ==  Double. NaN  | |  root  ==  Double . POSITIVE_INFINITY  | |  root  == 

Double. NEGATIVE_INFINITY  )  { 

103  times [0]  =  times [1]  =  root; 

104  }  else  { 

105  times [0]  =  (-b  -  root)/(2*a); 

106  times [1]  =  (-b  +  root) / (2*a) ; 

107  } 

108 

109  //System. out .println (  "times:  "+times[0]+"  "+times[l]  ); 

110 

111  return  times; 

112  } 

113  } 


The  results  from  the  above  code  represent  the  relative  times  of  penetration  and  exit,  if 
they  exist,  and  further  show  that  if  the  DISMover3D  was  already  inside  the  Sensor  range, 
times [0]  is  negative,  while  times [1]  being  negative  in  this  case  would  never  happen  since  the  ray 
does  not  terminate. 

This  is  fine  if  the  entity  in  question  is  small  in  comparison  to  the  Sensor  range.  However 
if  the  Sensor  range  is  small  in  comparison  to  the  Target ,  for  example  if  a  visual  contact  during 
maneuvers,  or  if  the  bounds  need  to  reflect  a  more  accurate  outline  of  collision  between  objects, 
some  refinement  may  be  required.  Diskit  optimizes  the  detection  by  breaking  the  problem  down 
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into  EnterRange/ExitRange  events  which  are  generalized  by  computing  low-cost  sphere 
intersection  regions.  From  there  a  higher-fidelity  model  may  be  used  to  further  see  if  an  actual 
Detection  happened.  This  factor  is  accounted  for  in  the  Mediator  class  for  the  particular  Sensor 
type,  as  shown  below  in  SphereCutter Mediator's  EnterRange  event  handler  for  example: 


1  public  void  doEnterRange (Sensor  sensor.  Mover 3D  target)  { 

2  Mover3D  contact  =  (Mover3D)  contacts . get (target) ; 

3  if  (contact  ==  null)  { 

4  contact  =  new  Contact (target) ; 

5  contacts .put (target,  contact); 

6  } 

sensor. waitDelay ("Detection",  0.0,  new  Object[]  {  sensor,  contact  }  ); 

8  } 


Two  things  are  worth  noting  about  the  above  code.  A  list  of  Contacts  is  maintained  for  all 
Mover  3D' s  in  range,  which  represent  distinct  positions  for  their  Mover3D's  which  helps  keep  the 
entities'  internal  operations  insulated  from  each  other.  Also  note  the  SphereCutterSensor  has  a 
0.0  time  delay  until  it  gets  a  Detection  event;  clearly,  any  algorithm  for  computing  time  delay 
can  be  inserted  instead. 

To  answer  the  question  at  the  beginning  of  this  section,  a  more  complex  Sensor  can  be 
supplied  by  the  user  along  with  a  Mediator  for  that  Sensor  that  can  calculate  a 
Detection/UnDetection  time  between  EnterRange  and  ExitRange  events,  given  enough 
information  from  the  Sensor  and  Mover3D  of  the  target.  Note  that  DISMover3D  is  an 
implementation  of  the  Diskit  Mover3D  interface. 

Below  are  the  Sensor  and  Mover  3D  interfaces  which  can  be  used  to  build  complex 
detection  algorithms. 

1  package  diskit; 

2 

3  import  java . util . Collection; 

4  import  simkit . SimEntity; 

5  import  simkit . smdx. Movement State; 

6 

7  /** 

8  * 

9  *  @author  ahbuss 

10  */ 

11  public  interface  Sensor  extends  SimEntity  { 

12 

13  public  Vec3d  getLocation () ; 

14 

15  public  Vec3d  getVelocity ( ) ; 

16 

17  public  MovementState  getMovementState () ; 

18 

19  public  double  getMaxRange () ; 

20 
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21 

22 

public 

23 

24 

public 

25 

26 

public 

27 

28 

public 

29 

30 

public 

31 

32 

public 

33 

} 

1 

/* 

2 

*  Mover 3D 

4  *  Created  on  October  6,  2004,  9:04  AM 

5  */ 

6 

7  package  diskit; 

8 

9  import  simkit . SimEntity; 

10  import  simkit . smdx. Movement State; 

11 
12 

13  public  interface  Mover3D  extends  SimEntity,  Locatable3D  { 


14 

15 

public 

16 

17 

public 

18 

19 

20 

public 

21 

public 

22 

23 

public 

24 

public 

25 

26 

//  thes 

27 

public 

28 

public 

29 

30 

public 

31 

//  gets 

32 

public 

33 

34 

35 

public  : 

36 

37 

public 

38 

39 

public 

40 

41 

public 

42 

43 

public 

44 

45 

public 

46 

47 

public 

48 

49 

public 

50 

51 

public 

52 

53 

public 

54  } 

MovementState  getMovementState ()  , 
TacticalMode  getTacticalMode ( ) ; 
String  getEntityType () ; 
void  stop(); 

void  setMoverlD (int  id); 
int  getMoverlD ( ) ; 
void  setForcelD (ForcelD  forcelD) , 
int  getForcelD ( ) ; 

String  getColor(); 

diskit .SMAL.SMAL  getSMAL(); 
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E.1.4  ScenarioManager 

Putting  it  all  together  is  the  ScenarioManager,  which  handles  registration  of  Sensors  and 
Targets  ( Locatable3D  components  of  Mover  3D's.)  Registration  is  simply  connecting 
propertyChangeListeners  and  simEventListeners,  adding  Mediators  in  an  automated  way. 
Entities  are  connected  to  the  ScenarioManager  so  that  the  manager  can  send  and  receive  events 
to  each,  and  upon  startup,  anything  that  can  be  a  Target  or  Sensor  reports  in.  The 
ScenarioManager  is  a  subclass  of  the  SensorTargetReferee ,  which  is  where  the  actual 
Intersector  3D  is  used  from  section  3 .  The  ScenarioManager  also  handles  any  other  kind  of 
contact  between  arbitrary  parties,  such  as  Munitions ,  Weapons,  Impact,  Escort  compliance,  and 
synchronization  with  DIS  packets. 

The  current  implementation  enables  quick  connection  of  SphereCutter Sensor's  and 
available  target  types,  however,  it  is  not  required  to  use  the  ScenarioManager' s  interface  to 
register  a  Sensor,  Target,  and  Mediator,  which  can  be  done  by  calling  upon  static  methods  of  the 
base  SensorTargetMediatorFactory. 


Figure  10.  Simple  SonarMediator  Event  Graph 
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The  above  example  from  diskit. SonarMediator. xml  generates  the  glue  code  between 
Diskit's  default  Sensor/T arget/Mediator  pattern,  and  our  customized  Sonar  sensor  (see  section 
1.3).  The  main  difference  is  that  instead  of  an  EnterRange  event  immediately  scheduling  a 
Detection  event,  the  Sonar  Sensor  receives  notification  that  it  is  time  to  start  checking  higher- 
fidelity  logic  encapsulated  within  the  Sonar's  event  graph. 

E.1.5  Example  Multisectioned  Log  Range  Attenuated  Transmission  Loss  Sonar 
(MiltiLRATL) 

With  the  above  interfaces,  we  can  now  construct  a  general  purpose  sensor  that  simulates 
attenuation  of  a  source  signal  as  it  propagates  and  calculates  a  Figure  of  Merit  (FOM)  for  the 
Detection  and  UnDetection  events.  The  sensor  starts  checking  versus  a  FOM  once  the  extreme 
boundary  sphere  has  been  penetrated,  but  only  if  the  Target  is  within  a  visible  section  of  the 
sensor.  The  example  below  shows  a  baffle  zone  or  blind  spot  where  no  FOM-based  detection  can 
be  checked.  Other  shapes  and  configurations  are  possible,  for  example  a  side  mounted  or  an 
omni-directional  sensor. 

Baffled  Sweep  Approximation: 


Figure  11.  Looking  Down  on  “Sweep” 
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Figure  12.  Baffle  Geometry  divided  into  triangular  sections,  viewed  from  above 


Figure  13.  Side  View  of  Approximation  Geometry.  First  cut,  “watermelon”  slices. 
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At  this  point,  we  can  generalize  to  more  simplified  forms  knowing  the  potential  intersections  at 
each  of  the  far  comers. 


Figure  14.  Further  Simplification  of  Volume  Geometry 


After  removing  the  bottom  subsection,  two  six-sided  volumes  for  this  slice: 


Figure  15.  Final  Geometry  of  Volume  Space 
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The  cross-section  shown  above  represents  only  one  of  several  that  get  checked;  the  sum 
total  make  up  a  complete  sensor  footprint  for  the  sake  of  a  single  Target's  Detection/UnDetection 
criteria. 

A  sensor  composing  these  six-sided  volumes  can  check  each  to  see  if  it  gets  penetrated 
by  the  velocity  vector  of  the  Target.  If  each  side  of  a  volume  is  defined  counter-clockwise,  then 
the  dot  product  is  always  negative  for  each  normal  vector  taken  as  a  dot  product  with  a  vector 
going  from  each  vertex  to  the  point  in  question  (if  that  point  is  inside  the  volume).  A 
computational  optimization  might  be  to  calculate  an  interior  point  of  the  facet  rather  than  check 
each  vertex. 

That's  fine  for  seeing  if  a  point  is  inside,  but  having  detected  a  ray  intersection  in  time, 
the  probability  of  detection  should  be  proportional  to  the  time  in  the  volume,  and  inversely 
proportional  to  the  square  of  the  distance  of  the  points  along  the  ray  to  the  center  of  the  beam. 

Another  technique  for  containment  is  to  use  energy  field  equations;  conceptually  taking 
the  line  integral  around  a  function  on  a  plane  that  contains  a  singularity  yields  a  non-zero 

number.  A  Cauchy  generating  function  for  this  in  complex  coordinates  might  be  j*  l/(z-z0)2dz . 

The  nice  property  is  that  the  anti-derivatives  in  this  case  are  bounded  by  simple  line 
segments  over  a  few  additions  and  subtractions  if  numerically  integrated.  This  generalizes  to  3D 
using  Greens  and  Stokes  Theorems  with  a  similar  generator. 

Once  the  ray  projected  from  the  moving  target  box  vertex  is  determined  to  be  within  a 

*1  j 

scan  volume,  probability  of  detection  could  be  approximated  by  J  AT - j  dt  where  K  is  some 

t0  (d(t)) 

constant  determined  by  parameters,  d  is  the  distance  to  the  point  at  time  t,  t  is  time  in  volume, 
and  where  d(t)  =|  (P(t)  -  C)  |=  J((P(t)-Cr)2  +  (P  (t)  -  Cy  )2  +  {P  (t)  -  C.  )2 )  . 

For  simplicity,  K  could  be  assumed  to  be  constant  throughout  the  ray,  so  volumes  should 
be  selected  to  represent  constant  regions. 

This  could  be  computationally  expensive,  another  simplification  may  be  to  state  a  “lock- 
in”  period  for  the  sensor,  inversely  proportionate  to  the  profile  area  of  the  target,  and 
proportionate  to  the  square  of  the  average  distance  and  some  constant.  Upon 
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Enter Range/ExitRange,  the  time  in  the  range  is  calculated,  the  probability  being  the  proportion 
of  the  time-in  to  the  lock-in  time;  greater  than  1.0  means  certain  detection. 

A  Detection  event  would  then  be  scheduled  at  the  first  certain  lock-in  time,  or  not  if  this 
time  is  after  the  ExitRange,  in  which  case  a  random  number  is  chosen  0.0-1 .0  that  if  below  the 
time  proportion  value  a  Detection  is  scheduled  during  the  lock-in  phase  depending  on  the 
proportion  of  the  random  variable  to  the  threshold.  ExitRange  for  simplicity  in  this  case  would 
schedule  the  UnDetection  of  the  Sensor,  since  it  is  “locked-in”.  Of  course,  if  a  target  was  in 
sufficiently  long  for  certain  lock  in,  there  could  be  the  same  possibility  that  a  detection  occurred 
during  the  lock-in  phase,  in  which  case  the  Detection  event  would  be  advanced  similarly. 

Then  it  actually  does  remain  to  determine  the  enter  and  exit  points  and  times  for  a  six- 
sided  volume  against  a  ray,  instead  of  calculating  a  probability  integral  directly  through  the 
volume  as  paragraph  prior  to  prior.  Fortunately,  the  ray  is  infinite  at  one  end.  Given  a  normal  to  a 
plane  and  a  center  point,  it  is  easy  to  see  where  a  ray  intersects  it,  solving  for  0,  however,  the 
intersection  point  still  needs  to  be  checked  vs.  the  facet  edges  to  see  if  it  is  inside  the  facet. 

Again  Cauchy's  integral  looks  interesting,  since  the  bounds  are  4  parameterized  vectors 
the  computation  is  relatively  cheap,  or  could  be  solved  by  residue  calculus.  Unfortunately,  the 
coordinates  are  not  transformed  to  the  Complex-Z  plane. 

Experimental  evidence  shows  that  generalization  to  3D  line  integrals  yields  reasonably 
good  results,  some  noise  near  very  sharp  comers  may  give  false  readings  depending  on  the 
integration  approximation  used.  Since  the  volumes  are  somewhat  regular,  very  sharp  comers 
should  not  be  a  concern,  and  furthermore  it  may  be  possible  to  solve  exactly  without  numerical 
integration. 

Even  so,  going  back  to  the  top,  it  might  be  just  as  fast  to  use  the  containment  test  by 
vector  and  dot  products,  divide  up  the  ray  into  the  least  reasonable  number  of  samples  between 
EnterRange  and  ExitRange  and  see  if  any  of  the  samples  are  captured,  then  take  the  amount  of 
time  between  captured  samples  for  the  ratio  test  in  each  volume. 
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Figure  16.  EnterRange  and  ExitRange  Point  Depicted 


At  this  stage  of  the  analysis,  one  of  two  paths  should  be  chosen,  subsample  the  ray  or 
check  for  bounds  intersection  on  the  facets.  Each  has  benefits  and  drawbacks. 

Back  to  the  “energy  potential”  calculus,  it  should  be  a  simple  calculation  provided  the 
force  function  is  selected  as  such.  The  idea  is  to  place  a  source  or  sink  at  the  test  point  of 
intersection  and  see  if  any  work  is  done  by  going  around  the  facet  edges.  This  technique  has  the 
benefit  that  the  winding  order  is  irrelevant,  anything  significantly  different  from  0  in  either  the 
positive  or  negative  direction  indicates  the  point  was  circumnavigated.  Another  benefit  to  this 
technique  is  it  instantly  generalizes  to  more  complex  regions  with  more  edges,  curves,  non- 
convex  contours,  3D  surfaces,  even  bow-ties  and  other  strange  shapes,  simply  by  supplying  a 
longer  list  of  vertices. 
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One  such  force  function  could  be  F(x,  y,  z)  =  i  !{x  -  x0 )  +  j  !{y  -  y0 )  +  k  /(z  -  z0 ) 


whose  partial  derivatives  are  easy  to  see,  and  will  blow  up  as  lim  F(r) . 

r-*r0 

Taking  the  line 

integral  J  F(r )  .d  r  =  |  (i  dx  !{x  -  x0)  +  (j  dy  /(y  -  y0)  +  (k  dz  !{z  -  z0 ))  parameterized  over  5  there 

are  4  line  segments,  as  5  goes  from  0  to  1  [(s09s1)9(s19s2)9(s29s3)9(s39s0)]  where  each  interval 
represents  the  parameterization  of  the  line  segment  from  each  vertex  to  the  next. 

A  line  segment  between  vertices  Vm  and  Vn  froms^  <  s  <  sn  is  represented  by 

rmn(s)  =  Vm(s-sn  / sm  -sn)  +  Vn(sm  ~s/sm -sn) .  Then 

fmn (5)  =  1  /(i,„  ls„)  +  \ym-Vn)s  +  Vnsm  -  Vmsn ] ,  or  expanded  out 

(s)  =  1  /(•?„,  -  s„ )  [(v„  -  v„  )s  +  vnxsm  -  v„as„  ] 

y  (s)  =  1/(5  -s  )  (v  -v  )s  +  v  s  -v  s 

•s  mn  x/  '  m  n/|_x  my  ny  J  ny  m  my  n  J 

Z  (5)  =  1/(5  —  5  )f(v  —V  )5  +  V  S  —V  S  1 

mn  V  /  \  m  « /  [ '  mz  nz  '  nz  m  mz  n  J 

Since  d  r(s)  =  dxi  +  dyi  +  dzk  ,  or  expanding  from  above, 

dx  /ds  =  (v  —v  )/(s  — s  ) 

dy  /ds  =  (v  —v  )/(s  — s  ) 

s  mn  V  my  ny  J  \  m  ns 

dz  /ds  =  (v  —v  )/(s  — s  ) 

The  integral  becomes  the  following,  where  n  is  consecutive  to  m  except  at  the  last  edge  of 
the  facet,  then  n  is  0: 

Z  0  L”  /(A»  -  sn  )KV,~  -  VmS„  ])  -  XQ  ] 

+  [j  /(I  -  s„  )[(v,„v  -  vny  )s  +  vnysm  -  vmysn  ])  -  y0  ] 

+  iw/(sm  -vjs  +  vmsm  -Vrosj)-z0] 

{*((vTO  -v„,)/(5,„ -s„)  +  j((vmy  —  vny ) /(sm -s„)  +  *(0v  -v„)/(j„ -s„)]ds 

which  can  now  be  simplified  for  s,  carrying  out  the  dot  product. 
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(v  —  V  ) 

First  let  axmn  =  — ^ - —  and  similarly  for  a  and  azmn  noting  they  represent  the 

(5  -s  ) 

derivatives  above,  and  in  the  algebraic  simplification  of  F  (omitted  for  brevity)  they  also  appear 
as  coefficients. 

Then  let  bxmr  vmsm~  vnus,i  anc^  similarly  for  bymrl,bzmn.  -phis  makes  each  term  of  the 

dot  product  in  the  integral  take  the  form - — - ,  or  with  a  factored  out, - — - —  and 

(as  +  b)-x0  {g  t  (b~. r„); 

a 

similarly  for  y  and  z.  Finally  this  yields  a  simple  integral  solution  in  terms  of  a  sum  of  natural 
logs,  carefully  noting  that  aa  's  and  ba  's  change  between  m  ’s  and  n  ’s  throughout  the  facet  edges 
as  above. 

Expanding  the  integral  in  terms  of  ds  gives 


{ (*  +  (6, -x0  )laj  +  (*  +  @,  ~ y0)/ay ) +  +  -zj/aj  * 
which  conveniently  solves  to 

TL 0 Ml  (S  +  Q>,  - x0 ) !(ax ))  I) I W  +  ln(|  (5  +  (by  - y0)/(a, ))  |)  %%  +  ln(|  (5  +  ( bz  - 


z„ )/(«-))  1)1 


(5n) 

(sm)  • 


An  optimization  in  the  algorithmic  expression  would  be  to  save  the  n's  as  the  next  m's. 
Again  note  above  M  ==  3  for  the  facet  shown,  and  n  is  consecutive  to  m  except  at  the  last  edge  of 
the  facet  where  n  is  0. 

With  that  we  now  have  an  easy-to-solve  equation  that  should  be  close  to  0  if  the  point  in 
question  isn’t  contained,  or  significantly  different  than  0  otherwise.  Now  an  algorithmic 
representation  can  be  defined.  While  possible,  it  isn't  important  to  describe  the  mathematical 
solution  in  terms  of  event  graphs,  but  clearly  the  graphs  should  be  able  to  implement  the  math  as 
a  utility. 

The  above  treatment  should  also  be  considered  for  implicit  surfaces,  replacing  the  vertex 
calculations  for  the  equation  for  the  surface.  For  example  the  cardioid 
x  =  r/(z  +  a)2  cos  0,  y  =  r  !(z  +  a)2  sin  0  would  trace  out  a  forward  facing  cardioid  volume. 
However,  using  the  6-sided  polygon  enables  more  varied  shapes  to  easily  be  constructed,  if  only 
at  the  cost  of  more  intersection  tests. 
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In  practice  however,  the  above  treatment  is  rather  complex  and  more  research 
examination  would  be  needed  to  test  the  equations,  and  ultimately  a  simplified  geometry  may  be 
easier  to  implement;  instead  of  trying  to  solve  the  generalized  case  of  intersection  against  a 
possibly  concave  or  bow-tied  perimeter,  establishing  a  prerequisite  that  all  facets  are  convex 
greatly  simplifies  the  problem  to  just  a  few  vector  cross-products. 

The  following  code  section  makes  the  convex  assumption  about  the  Facet's  shape,  then 
each  ray  extending  from  each  vertex  through  any  sample  point's  cross-product  with  the  Facet's 
normal  will  all  be  in  the  same  direction  if  the  sample  point  is  inside  the  facet,  or  not,  if  it  is 
outside. 


1  /* 

2  *  Facet. java 

3  * 

4  *  Created  on  May  20,  2006,  8:45  PM 

5  * 

6  */ 

7  package  diskit; 

8 

9  import  diskit. util. Transform; 

10 

11  /** 

12  * 

13  *  @author  Rick  Goldberg 

14  */ 

15  public  class  Facet  { 

16  Vec3d[]  vertices; 

17  public  static  final  double  epsilon  =  .1; 

18  private  double  tint  =  0.0; 

19 

20  public  static  String[][]  parameterMap  =  new  String [][]  { 

21  { 

22  " diskit. Vec3d[] ",  "vertices" 

23  } 

24  }  ; 

25 

26  private  static  final  boolean  debug  =  false; 

27 

28 

29  /**  Creates  a  new  instance  of  Facet 

30  *  Assumes  vertices  are  in  ccw  order  about  the  perimeter, 

31  *  looking  down  Z+  and  all  affine  rotations,  and  that  there  are  N>2  of  them,  and 

32  *  no  vertices  are  sequentially  duplicated.  The  Facet  is  convex! 

33  */ 

34  public  Facet (Vec3d [ ]  vertices)  { 

35  this .vertices  =  new  Vec3d [vertices . length  +  1] ; 

36  for  (  int  i  =  0;  i  <  vertices . length;  i  ++)  { 

37  this .vertices [i]  =  new  Vec3d (vertices [i] ) ; 

38  if  (debug)  System. out .println ("Vertex  ["+i+"]  "+vertices [i] ) ; 

39  } 

40  //  add  an  extra  vertex  at  the  end  to  simplify  loop  around 

41  this .vertices [vertices . length]  =  new  Vec3d (vertices [0] ) ; 

42  } 

43 

44  /**  Given  a  location  and  a  direction,  calculate 

45  *  intersection  point,  or  null  if  none 

46  */ 

47  public  Vec3d  intersect (Vec3d  point,  Vec3d  direction)  { 

48  Vec3d  pt  =  new  Vec3d(); 
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//  create  normal  to  plane  for  plane  vs.  ray  intersect 
Vec3d  v0  =  new  Vec3d (vertices [1] ) ; 

Vec3d  vl  =  new  Vec3d (vertices [ 1 ]) ; 
vO . sub (vertices [0] ) ; 
vl . sub (vertices  [ 2 ] ) ; 

//  calculate  normal  to  plane 
Vec3d  normal  =  new  Vec3d(); 
normal. cross (v0,vl) ; 
normal . normalize ( ) ; 

//  calculate  constant  D  for  plane  eqn 
//  with  normal  N  =  (A,B,C) 

//  Ax  +  By  +  Cz  =  D 

//  for  some/any  vertex  point 

double  d  =  normal .get (0) * vert ices [0] .get (0)  +  normal . get (1) *vertices [0] . get (1)  + 
normal. get (2) *vertices [0] .get (2)  ; 

if  (debug)  System.out .println ("Normal  to  plane  is  "+normal) ; 
if  (debug)  System. out .println ( "Plane  Constant  D  is  "+d) ; 

//  find  intersection  from  point  along  direction  to  plane 
//  solve  for  t  parametrically,  ray  becomes 
//  point  +  direction  *  t  as  0  <  t  <  inf 
//  or 

//  x ( t )  =  p [0]  +  d [ 0]  *  t 

//  y(t)  =  p [1]  +  d[l]  *  t 

//  z  ( t )  =  p  [2 ]  +  d [2]  *  t 

//  then  for  t 

//  t  =  {D  -  [  N  [  0  ]  *P  [  0  ]  +  N  [  1  ]  *P  [  1  ]  +  N  [2  ]  *P  [2  ]  }  /  {  N[0]*V[0]  +  N[1]*V[1]  + 

N  [2 ]  *V  [2 ]  } 
double  t; 

double  nx,  ny,  nz,  px,  py,  pz,  dx,  dy,  dz; 

nx  =  normal . get (0) ; 

ny  =  normal . get (1) ; 

nz  =  normal . get  (2) ; 

px  =  point .get (0) ; 

py  =  point .get (1) ; 

pz  =  point .get (2) ; 

dx  =  direction. get  (0) ; 

dy  =  direction. get  (1) ; 

dz  =  direction. get  (2) ; 

try  { 

t  =  (  d  -  (  nx*px  +  ny*py  +  nz*pz  )  )  /  (  nx*dx  +  ny*dy  +  nz*dz) ; 

}  catch  (java. lang. Except ion  e)  { 

//  divide  by  zero  means  parallel 
return  null; 

} 

if  (debug)  System.out .print ("t  intersect  parameterized  at  "+t+"  "); 

if  (debug) if  (t<=0 . 0) System. out .println ( "Never  intercepts,  going  backwards  then..."); 
//  then  substitute  back  into  line  eqn  to  get  point  from  t 
// 

pt . set (0, px+dx*t) ; 
pt . set  ( 1 , py+dy * t ) ; 
pt . set  (2, pz+dz*t) ; 
if  (debug)  System.out .println (pt) ; 

//  check  containment  of  perimeter  defined  by  vertices,  or  return  null  if  not 
contained 

//  see:  "Diskit  Sensor  and  Mover  Dynamics"  section  5 

//  In  terms  of  DIS  coordinates,  looking  down,  in  the  +z  direction, 

//  a  non-concave  facet  is  wound  ccw  iff  every  surface  normal 

//  points  up,  -z  direction,  as  calculated  by  drawing  a  vector  from  each 

//  vertex  to  the  previous  and  the  next  in  the  order  given. 

//  ie 

//  N (Vm)  =  (Vm-1  -  Vm)  X  (  Vm+1  -  Vm) 

//  We've  already  calculated  a  normal,  and  it  adheres  to  this 
/ /  convention 

//  For  a  point  anywhere  on  the  plane  P  will  be  inside  the 
//  facet  if  for  each  Vm 
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//  C (Vm)  =  (P-  Vm)  x  (  Vm+1  -  Vm) 

//  C(Vm)  is  in  same  direction  as  N 
//  or 

//  C (Vm)  .  N  >  0 

//  and  if  C (Vm)  is  normalized  by  its  length 
//  C (Vm)  .  N  ==~  1.0 

//  so  that  Sum  (  C  (  Vm) ,  m=0,M  )  ==~  M  if  P  is  inside  the  facet. 


//  recall  0th  is  copied  to  vertices [vertices . length] 

//  numEdges  is  vertices . length-1 
double  nE  =  (double) vertices . length-1 . 0; 

if  (debug)  System. out .println ("Edge  determinator  nE  "+nE) ; 

Vec3d  pO  =  new  Vec3d(pt); 

for  (  int  i  =  0;  i  <  vertices . length-1;  i++)  { 

Vec3d  VI  =  new  Vec3d (vertices [i+1] )  ; 

VI . sub (vertices  [i] ) ; 

Vec3d  VP  =  new  Vec3d(p0); 

VP. sub (vertices  [i]  )  ; 

VP. cross (VI) ; 

VP. normalize ( ) ; 
nE  -=  VP . dot (normal) ; 

if  (debug)  System. out .println ("nE  =>  "+nE) ; 

} 

if  (  Math.abs(  nE  )  <  epsilon  )  { 

//  bingo  ! ! 

if  (debug)  System. out .println (pt+  "  is  inside  facet"); 
this. tint  =  t; 
return  pt; 

} 

return  null; 

} 

j  *  * 

*  same  as  intersect ()  except  returns  time  of  intersection 

*  in  vec[3]  as  part  of  a  Vec4d 
*/ 

public  Vec4d  intercept (Vec3d  point,  Vec3d  velocity)  { 

Vec3d  intersection  =  intersect (point ,  velocity); 
if  (  intersection  !=  null)  { 

Vec4d  interception  =  new  Vec4d(intersection.get (0) ,  intersection. get (1) , 
intersection. get (2) ,  tint); 
return  interception; 

} 

return  null; 

} 

J  *  * 

*  returns  a  copy  of  the  Facet  as  transformed 
*/ 

public  Facet  transform (Transform  t)  { 

Vec3d[]  verts  =  new  Vec3d [vertices . length-1 ] ; 
for  (  int  i  =  0;  i  <  verts . length;  i++)  { 
verts  [i]  =  new  Vec3d(  vertices [i]  ); 
t. transform (verts [i]  )  ; 

} 

return  new  Facet (verts) ; 

} 
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With  the  above  transformable  Facet ,  now  a  solid  can  be  assembled  as  per  the  prior 
diagrams.  This  will  be  the  basic  building  block  for  the  sensor's  capture  volumes,  the 
QuadVolume  provides  the  same  simple  intersect  method  as  the  Facet,  a  call  to  intersect  causes 
QuadVolume  to  call  intersect  on  all  its  Facets. 


QuadVolume . j  ava 

Created  on  June  15,  2006,  5:00  PM 


1 
2 

3 

4 

5  * 

6  */ 

7 

8  package  diskit; 

9  import  diskit .util .Transform; 
10 

11  /** 

12  * 

13 

14 


@author  Rick  Goldberg 
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15  public  class  QuadVolume  { 
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//  assumptions:  this  is  a  volume  with  6x4  sided  facets 
protected  Facet []  facets; 
protected  Transform  transform; 

public  static  String[][]  parameterMap  =  new  String [][]  { 

{ 

" dis kit . util . Transform" ,  "transform" , 


"diskit . Facet" 
"diskit . Facet" 
"diskit. Facet" 
"diskit . Facet" 
"diskit . Facet" 
"diskit . Facet" 


"top", 

"bottom", 

"front" , 

"back", 

"left", 

"right" 


}, 

{ 


" dis kit . util . Transform" ,  "transform" , 
"diskit . Facet [] ",  "facets" 


}  ; 
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top 

36 

// 
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bottom 
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front 
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// 
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back 

39 

// 
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left 

40 

// 

5 

right 

public  QuadVolume (Transform  transform.  Facet  top,  Facet  bottom.  Facet  front.  Facet  back, 
Facet  left.  Facet  right)  { 
this . transform  =  transform; 
this. facets  =  new  Facet [6]; 
this . facets [0]  =  top . transform (transform) ; 
this . facets [1]  =  bottom. transform (transform) ; 
this . facets [2]  =  front . transform  (transform) ; 
this . facets [3]  =  back. transform (transform) ; 
this . facets [4]  =  left . transform (transform) ; 
this . facets [5]  =  right . transform (transform) ; 

} 

public  QuadVolume (Transform  transform,  Facet []  facets)  { 
this . transform  =  transform; 
this. facets  =  new  Facet [6]; 

for  (  int  i  =  0;  i  <  facets . length;  i++  )  { 

this . facets [i]  =  facets [i] . transform (transform) ; 

} 

} 
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60 

61  protected  QuadVolumeO  { 

62  this (new  Transform(),  new  Facet [ 0 ] ) ; 

63  } 

64 

65  //  find  interception  points  in  time  (  v0,vl,v2,t0  ) 

66  //  against  the  6  sided  volume 

67  //  should  return  2  points,  or  null 

68  public  Vec4d[]  intercept (Vec3d  point,  Vec3d  velocity)  { 

69  Vec4d[]  interceptions  =  new  Vec4d[6]; 

70  Vec4d[]  intercepts  =  new  Vec4d[2]; 

71  int  c  =  0; 

72  for  (  int  i  =  0;  i  <  6;  i  ++  )  { 

73  Vec4d  v  =  facets [i] . intercept (point , velocity) ; 

74  if  (v  ! =  null)  { 

75  interceptions [C++]  =  v; 

76  } 

77  } 

78  //  there  should  be  either  2  times  or  none 

79  //  could  be  edge  or  vertex 

80  if  (c>l)  { 

81  intercepts  [0]  =  interceptions [0] ; 

82  final  double  eps  =  .01; 

83  for  (  int  i  =  0;  i  <  c;  i++)  { 

84  if  (  Math. abs (intercepts [0] .get (3)  -  interceptions [i] .get (3) )  >  eps)  { 

85  intercepts [1]  =  interceptions [i] ; 

86  break; 

87  } 
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} 

//  check  possible  edge/corner  condition 

if  (intercepts [1]  ==  null)  intercepts [1]  =  intercepts [0] ; 
//  return  them  sorted  in  time 

if  (  intercepts [0] .get (3)  >  intercepts [1] . get (3) )  { 

Vec4d  tmp  =  intercepts [0] ; 
intercepts [0]  =  intercepts  [  1 ] ; 
intercepts [1]  =  tmp; 

} 

return  intercepts; 

} 

else  return  null; 


Finally  a  Sonar  Scan  can  be  assembled  from  an  array  of  QuadVolumes.  In  this  case, 
SonarScan  will  create  the  “pie-sliced  inwardly-squashed  semi-cylinder”  as  depicted  earlier, 
however  any  grouping  of  arbitrary  6-sided  shapes  can  be  similarly  constructed.  Furthermore,  in 
the  SonarScan  object,  16  such  volumes  are  created  omni-directionally  and  stacked  in  2  layers  of 
8,  each  of  which  is  only  checked  if  it  is  marked  “on”,  and  by  default  they  are  all  on. 

A  correction  factor  is  used  to  adjust  the  radial  endpoints  to  just  beyond  the  outer 
bounding  sphere,  such  that  the  far  edges  only  touch  the  sphere  at  one  point  each.  This  is  done 
because  it  is  better  to  check  and  detect  nothing  than  not  to  check  when  there  could  be  something 
detectable. 
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Figure  1 8.  Showing  Comparison  between  an  Inner  and  Outer  Approximation  to  the  Sphere  by  a 

Facet. 


Since  these  wedges  are  n!  4  radians,  the  radial  correction  factor  is  1.0/0.707. 


1  /* 

2  *  SonarScan. java 

3  * 

4  *  Created  on  September  1,  2006,  10:20  AM 

5  * 

6  *  Creates  a  set  of  QuadVolumes  that  form  a  sort  of  layered-pie. 

7  * 

8  */ 

9 

10  package  diskit; 

11  import  diskit. util. Transform; 

12  import  diskit . Facet ; 

13  import  java. util. Vector; 

14 

15  /** 

16  * 

17  *  @author  Rick  Goldberg 

18  */ 

19  public  class  SonarScan  { 

20 

21  Transform  transform; 

22  double  maxRange; 

23  QuadVolume [ ] [ ]  scanVolumes  =  new  QuadVolume [8] [2] ; 

24  //  looking  down  z,  with  x  in  front,  going  the  8  xy  slices 

25  //  three  parallel  polylines  trace  out  the  sphere  latitudinally  from  the  equator, 

26  //  fourth  and  pole  not  used 

27  Vec3d[]  topEdge  =  new  Vec3d[8]; 

28  Vec3d[]  midEdge  =  new  Vec3d[8]; 
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Vec3d[]  botEdge  =  new  Vec3d[8]; 

private  boolean [][]  activeVolumes  =  new  boolean [ 8 ] [2 ] ;  //  check  activeVolume [0] [n] 
forward  right,  [7] [n]  forward  left 


/if  if 

*  Creates  a  new  instance  of  SonarScan 

*  Simplifies  creating  scan  wedges  of  QuadVolumes  that  contain  portions  of  a  sphereical 
volume . 

*  Sets  up  8  sectors,  which  are  2  layers  deep,  for  a  total  16  QuadVolumes. 


public  SonarScan (Transform  transform,  double  maxRange)  throws  IllegalArgumentException  { 

this . transform  =  transform; 
this .maxRange  =  maxRange; 

//  adjustment  factor,  to  circumscribe  the  sphere  with  planars  instead  of  other  way 
around 

//  generate  these  radii 

double  topL  =  maxRange/Math . cos (Math. PI/4 . 0) ; 
double  topH  =  0.0; 

double  midL  =  topL  *  Math. cos (  (  1.0/ 8.0  )  *  Math. PI  ); 

double  midH  =  topL  *  Math.sin(  (  1. 0/8.0  )  *  Math. PI  ); 

double  botL  =  topL  *  Math. cos (  (  1. 0/4.0  )  *  Math. PI  ); 

double  botH  =  topL  *  Math.sin(  (  1. 0/4.0  )  *  Math. PI  ); 

for  (  int  i  =  0;  i  <  8;  i++  )  { 

double  angle  =  ( (double) i  )  *  Math. PI  /  4.0; 

topEdge[i]  =  new  Vec3d (topL*Math. sin (angle) , topL*Math . cos (angle) , topH) ; 
midEdge[i]  =  new  Vec3d(midL*Math. sin (angle) ,midL*Math. cos (angle)  , midH) ; 
botEdge[i]  =  new  Vec3d (botL*Math. sin (angle) ,botL*Math . cos (angle) , botH) ; 

} 

scanVolumes  =  createVolumes () ; 


} 

//  see  order  in  createVolumes  ...  [8] [2] 
public  void  setActiveVolumes (boolean [][ ]  volumes)  { 
this . activeVolumes  =  volumes; 

} 

public  QuadVolume [ ] [ ]  createVolumes ( )  { 

//  create  2  layers 

for  (  int  i  =  0;  i  <  2;  i++  )  { 

//  of  8  slices 
Vec3d[]  tops,  bottoms; 

if  (  i  ==  0  )  { 

tops  =  topEdge; 
bottoms  =  midEdge; 

}  else  {  //  i==l 

tops  =  midEdge; 
bottoms  =  botEdge; 

} 

for  (  int  j  =  0;  j  <  8;  j++  )  { 

int  k  =  (  j  ==  7  )  ?  0  :  j  +  1; 

Facet  top,  bottom,  front,  back,  left,  right; 

Vec3d  scaledK,  scaledJ; 

scaledK  =  new  Vec3d (tops [k] ) ;  scaledK. scale (. 001) ; 
scaledJ  =  new  Vec3d (tops [ j ] ) ;  scaledJ. scale (. 001) ; 

top  =  new  Facet (new  Vec3d[]  {  new  Vec3d (tops [ j ] ) ,  new  Vec3d (tops [k] ) , 
scaledK,  scaledJ  }  ) ; 

scaledK  =  new  Vec3d (bottoms [k] ) ;  scaledK. scale (. 001 )  ; 
scaledJ  =  new  Vec3d (bottoms [j ]) ;  scaledJ. scale (. 001 ) ; 
bottom  =  new  Facet (new  Vec3d[]  {  new  Vec3d (bottoms [j ]) ,  new 
Vec3d (bottoms [k] ) ,  scaledK,  scaledJ  }  ); 

front  =  new  Facet (new  Vec3d[]  {  new  Vec3d (tops [ j ] ) ,  new  Vec3d (tops [k] ) ,  new 
Vec3d (bottoms [k] ) ,  new  Vec3d (bottoms [j ] )  }  ); 
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//  technical  note  on  right  and  left,  these  may  actually  be  getting  created 
reversed  here  (tbd  test) ,  however, 

//  mediator  makes  time  calculations  that  make  it  irrelevant,  including  ccw 
order 

//  note  k  for  both 

scaledK  =  new  Vec3d (tops [k] ) ; 

scaledK. scale ( . 001) ; 

scaledJ  =  new  Vec3d (bottoms [k] ) ; 

scaledJ. scale ( . 001) ; 

left  =  new  Facet (  new  Vec3d[]  {  new  Vec3d (tops [k] ) ,  new  Vec3d (bottoms [k] ) , 
new  Vec3d (scaledJ) ,  new  Vec3d (scaledK)  }); 

//  note  j  for  both 

scaledK  =  new  Vec3d  (tops [ j ] ) ; 

scaledK. scale ( . 001) ; 

scaledJ  =  new  Vec3d (bottoms [j ]) ; 

scaledJ. scale ( . 001) ; 

right  =  new  Facet (  new  Vec3d[]  {  new  Vec3d (tops [ j ] ) ,  new  Vec3d (bottoms [j ]) , 
new  Vec3d (scaledJ) ,  new  Vec3d (scaledK)  }); 

//  back 

Vec3d  scaledTK  =  new  Vec3d (tops [k] ) ; 
scaledTK. scale ( . 001) ; 

Vec3d  scaledTJ  =  new  Vec3d (tops [ j ] ) ; 

scaledTJ. scale ( . 001) ; 

scaledK  =  new  Vec3d (bottoms [k] ) ; 

scaledK. scale ( . 001) ; 

scaledJ  =  new  Vec3d (bottoms [j ]) ; 

scaledJ. scale ( . 001) ; 

back  =  new  Facet (  new  Vec3d[]  {  scaledTK,  scaledTJ,  scaledJ,  scaledK  }); 


scanVolumes [ j ] [i]  =  new 

QuadVolume (transform, top, bottom, front, back, left, right) ; 
activeVolumes [ j ] [i]  =  true; 

} 

} 

return  scanVolumes; 

} 

public  Vector  intercept (Vec3d  point,  Vec3d  velocity)  { 

Vector  v  =  new  Vector (); 

for  (  int  i  =  0;  i  <  2;  i  ++  )  { 

for  (  int  j  =  0;  j  <  8;  j++  )  { 
if  (activeVolumes [j ] [i] )  { 

Vec4d[]  intercepts  =  scanVolumes [j ] [i] . intercept (point, velocity) ; 
if  (intercepts  !=  null)  { 
v . add ( intercepts )  ; 

} 

} 

} 

} 

return  v; 

} 


Now  that  a  contact  location  strategy  has  been  determined,  it  remains  to  integrate  the 
FOM  of  detection  within  the  capture  volume(s).  There  are  a  number  of  factors  which  can 
contribute  to  the  quality  of  a  signal,  such  as  ambient  noise,  frequency,  initial  energy,  and  Target 
geometry. 
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In  signal  analysis  it  is  customary  to  represent  energy  levels  in  terms  of  Decibels  (dB),  in 
large  part  because  perception  of  loudness  is  logarithmic  for  both  biological  and  electro¬ 
mechanical  devices.  Using  the  equations  for  sonar  signaling  as  presented  by  Sonalyts,  Inc.,  a 
detection  threshold  can  readily  be  implemented  in  terms  of  Diskit's  Mover  and  Sensor  dynamics. 

The  principle  behind  the  Sonalysts  FOM  equation  is  that  overall  signal  integrity  is 
composed  of  several  factors,  and  in  terms  of  transcendental  mathematics,  logarithms  add  or 
subtract  as  factors  multiply  and  divide.  This  greatly  simplifies  quantitative  results.  So  for 
example  one  could  say  return  on  a  signal  is  proportional  to  the  inverse  of  the  square  of  the 
distance  (and  other  factors),  in  terms  of  logs  that  becomes  ”  21ogX  (+/_  other  factors.) 

Once  sufficient  factors  can  be  approximated,  an  overall  summation  of  the  signal  in  terms 
of  dB  can  be  constructed,  including  the  amount  of  raw  signal  required  for  an  operator  to 
positively  differentiate  between  noise  and  target  reflection. 


Let: 

SL  =  Signal  Strength  of  Ping 

TL  =  Transmission  Loss  of  signal  spread,  approximately  10  log(range)  overall  20 
log(range)  to  account  for  the  loss  of  the  signal  on  its  return. 

TS  =  Target  Strength,  a  figure  dependent  upon  shape,  orientation,  and  c 
composition  of  the  target 

NL  =  Noise  Level  of  ambient  sound 

DI  =  Directivity  Index,  noise  filter  capability  of  the  sonar 

RD  =  Recognition  Differential,  can  be  operator  skill  level,  or  a.k.a.  DT  as 
Detection  Threshold 

AT  =  Attenuation  loss  due  to  frequency  of  signal, 

(1 2  / 1 1)  *  (0.003  +  0.  If2  /(I  +  f2 )  +  (40  f2 )  /(4 1 00  +  /2 )  +  0.000275 f2 ) 

Then: 

if  SL  -  2{TL)  +  TS  -  (NL  -  DI)  -  RD  -  AT  >  0  a  detection  event  happens  and  conversely  if  <  0,  an 

UnDetection  may  happen  if  already  detected. 
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Frequency 

Attenuation 

3.5  kHz 

.22  dB/kyd  (.24  dB/km) 

10  kHz 

1.08  dB/kyd  (1.19  dB/km) 

30  kHz 

7.55  dB/kyd  (8.31  dB/km) 

60  kHz 

19.79  dB/kyd  (21.77  dB/km) 

100  kHz 

31.22  dB/kyd  (34.34  dB/km) 

Table  2.  Table  showing  sample  values  of  AT  used  for  various  frequencies  of  interest. 


Some  of  these  factors  can  be  considered  constant  inputs  to  the  equation,  such  as  SL  ox  AT, 
whereas  other  factors  can  have  some  randomness,  such  as  RD  (if  say  the  operator  was  distracted) 
or  NL  since  noise  levels  are  themselves  “noisy”.  The  MultiLRATL  Sonar  model  enables  the 
analyst  to  set  variously  shaped  random  variates  for  input  parameters,  so  for  example  if  RD  of  a 
skilled  operator  is  measured  to  be  typically  10.0  dB,  the  operator  may  have  a  standard  deviation 
perhaps  by  1 .0  in  a  Normal  Gaussian  distribution.  Similarly  NL  might  be  also  60  dB  with  a 
standard  deviation  of  5.0  in  a  particular  harbor. 

Perhaps  the  region  has  some  areas  that  are  noisier  than  others,  and  data  are  available  at 
regular  intervals  for  noise  levels,  then  a  map  can  be  constructed  using  Diskit’s 
InterpolatedXYVariate ,  which  is  a  drop-in  replacement  for  any  abstract 
simkit. random. RandomVariate  parameter,  incidentally  using  the  above-mentioned  Facet  to 
perform  the  interpolation. 


1  /* 

2  *  InterpolatedXYVariate . java 

3  * 

4  *  Created  on  July  9,  2006,  11:07  AM 

5  * 

6  *  An  M  x  N  grid  in  X,Y,  where 

7  *  Xm  =  m  *  Dx/Dm  +  X0 

8  *  Yn  =  n  *  Dy/Dn  +  Y0 


9  */ 

10  package  diskit; 

11 

12  import  simkit . random . RandomVariateBase ; 

13 

14  /** 

15  * 

16  *  @author  Rick  Goldberg 

17  */ 

18  public  class  InterpolatedXYVariate  extends  RandomVariateBase  { 

19  public  static  double  MAX_Z  =  1000.0; 

20  double  xScale;  //  Dx/Dm 

21  double  xShift;  //  X0 

22  double  yScale;  //  Dy/Dn 

23  double  yShift;  //  Y0 
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Double[] []  zValues;  //  zValues [  y  rows  ] [  x  columns  ] 
double  x,y;  //  sample  point 
Facet  quad; 


/**  Creates  a  new  instance  of  InterpolatedXYVariate  */ 
public  InterpolatedXYVariate ( )  { 
setXScale  (1.0) ; 
setXShift (0.0) ; 
setYScale  (1.0) ; 
setYShift (0.0) ; 
setX (0 . 0) ; 
setY (0.0) ; 

//  initially  make  a  flat  2x2  of  z  values,  generally  by  row[0],  row[l]  ...  row[n] 
Object []  zGrid  =  new  Object []  {  new  Doublet]  {  new  Double  (0.0),  new  Double (0.0)  }  , 

new  Doublet]  {  new  Double (0.0),  new  Double (0.0)  }  }; 
setParameters (zGrid)  ; 

} 

//  x,y  should  be  set  each  generate (),  otherwise  this  behaves  like  a  constant  variate, 

//  unless  data  was  touched, 
public  double  generate ()  { 

int  xl,  xj,  yl,  yj;  //  index  into  zValues 
double  xO  =  x/xScale  -  xShift; 
double  yO  =  y/yScale  -  yShift; 

//  first  xl,  to  be  low  x  index,  then  xl+l  is  hi 
xl  =  (int)xO; 
xj  =  xl  +  1; 

//  clamp  to  edge  of  map 

if  (  xJ  >  zValues [0] .length  )  { 
xJ  =  zValues [0] . length; 
xl  =  xJ  -  1; 

} 

if  (  xl  <  0  )  { 
xl  =  0; 
x  J  =  1  ; 

} 

yl  =  (int) (yO) ; 
yj  =  yl  +  1; 

if  (  yj  >  zValues . length  )  { 
yj  =  zValues . length; 
yl  =  yj  -  1; 

} 

if  (  yj  <  0  )  { 
yj  =  1; 

yl  =  0; 

} 


Vec3d[]  verts  =  new  Vec3d[4]; 
verts  [0]  =  new  Vec3d (  (double) xl,  (double) yl, 
verts [1]  =  new  Vec3d (  (double) xl,  (double) yJ, 
verts [2]  =  new  Vec3d(  (double) xj,  (double) yJ, 
verts [3]  =  new  Vec3d (  (double) xj,  (double) yl, 


(zValues  [yl]  [xl] ) 
(zValues [yJ] [xl] ) 
(zValues [yJ] [xj] ) 
(zValues  [yl]  [xj] ) 


. doubleValue ()  ) 
. doubleValue ()  ) 
.doubleValue ()  ) 
.doubleValue ()  ) 


//  can  carry  out  the  interp  in  normalized  space,  same  result  as  full  x, y  coords 
quad  =  new  Facet (verts); 


//  using  the  4d  version  don't  really  need  a  MAX_Z,  can  be  backwards  in  'time',  but 
//  preserving  sense  of  +z  down  could  also  be  used  for  terrain;  orig.  intent  was  for 
noise 

//  intensity  and  other  data  however. 


Vec4d  intercept  =  quad. intercept (  new  Vec3d (xO, yO, -MAX_Z) ,  new  Vec3d (0 . 0, 0 . 0, 1 . 0)  ); 
return  intercept. get (2); 
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/*  Parameters  are  object [N]  =  Double [M] 

*  of  Z  values . 

*/ 

public  void  setParameters (Object []  object)  { 
int  N  =  object . length; 
for  (  int  n  =  0;  n  <  N;  n++  )  { 

zValues[n]  =  (Double []) object [n] ; 

} 

} 

/*  returns  actual  data,  not  a  copy 
*/ 

public  Object []  getParameters ( )  { 

Object []  ret  =  new  Object [zValues . length] ; 
for  (  int  n  =  0;  n  <  zValues . length;  n  ++)  { 
ret [n] =zValues [n] ; 

} 

return  ret; 

} 

public  void  setYShift (double  d)  { 
yShift=d; 

} 

public  void  setXShift (double  d)  { 
xShift=d; 

} 

public  void  setXScale (double  d)  { 
xScale=d; 

} 

public  void  setYScale (double  d)  { 
yScale=d; 

} 

public  void  setX  (double  d)  { 
x=d; 

} 

public  void  setY (double  d)  { 
y=d; 

} 


A  quote  from  (Urick  1986)  and  commentary  courtesy  Douglas  Nelson,  Sonalysts,  Inc.: 

No  measurement  work  in  the  real  ocean  has  been  done  in  this  frequency  range, 
except  for  the  measurements  of  Anderson  And  Gruber  at  30,  90  and  150  kHz  in 
the  ports  of  San  Diego,  Long  Beach  in  California,  Balboa  and  Christobal  in  the 
Pacific  Canal  Zone,  and  Norfolk,  Virginia.  These  locations  were  found  to  be 
extremely  noisy  and  showed  great  variability  from  port  to  port.  The  average 
levels  in  these  ports  was  some  20  dB  higher  than  the  Knudsen  extrapolated  levels 
for  sea  state  6.  Surprisingly  small  differences  were  found  between  day  and  night; 
the  lower  levels  due  to  industrial  activity  during  the  night  were  evidently 
compensated  by  higher  noise  due  to  snapping  shrimp.  Comparing  the  various 
ports,  there  was  a  general  tendency  for  the  noise  levels  to  increase  with  decreasing 
latitude,  as  would  be  expected  from  greater  abundance  of  shrimp  in  lower 
latitudes. 
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From  the  Knudsen  curves,  we  should  expect  average  noise  levels  to  be  66  dB  at  30  kHz, 
57  dB  at  90  kHz,  and  53  dB  at  150  kHz.  Going  by  Urick's  comment  on  latitudes,  we  should 
probably  give  Bremerton  and  Annapolis  lower  values  and  Pearl  a  higher  value.  Interesting 
points  are  the  small  differences  noted  between  day  and  night,  and  that  wind/sea  state  related 
noise  is  completely  dominated  by  other  sources. 

These  random  factors  generate  discrete  values  each  time  they  are  sampled  by  a  “Ping” 
from  the  MultiLRATLSonar.  The  net  result  is  they  define  a  probability  of  detection  that  tapers  off 
at  the  furthest  maximum  range  as  denoted  by  the  Mediator's  detection  sphere;  consequently,  a 
Sensor  should  be  initialized  with  its  maximum  range  parameter  calculated  to  be  that  where 
factors  such  as  NL  or  RD  are  at  their  best. 

There  are  now  sufficient  components  to  assemble  a  working  model  within  Viskit.  The 
following  shows  the  Event-Graph  layout  and  generated  code  for  the  MultiLRATLSonar ,  at  which 
point  it  will  be  dropped  into  an  existing  SMAL-based  sample  scenario  from  the  ATFP 
Behavior  Libraries. 
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Figure  19.  CheckDetection  Event  Graph 


Once  the  CheckDetection  event  is  heard  from  the  Mediator ,  a  number  of  Pings  are 
scheduled  while  the  potential  Target  is  sampled  throughout  its  traversal  of  the  SonarScan 
volume.  If  the  FOM  >  0.0  a  Detection  occurs,  otherwise  UnDetection  occurs  if  already  detected. 
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This  event  graph  generates  the  following  runnable  code: 


1  package  diskit; 


2 

3  import 

4  import 

5  import 

6 

7  public 

8 


simkit . *; 
s imki t . random . *  ; 
java. util. *; 

class  MultiLRATLSonar  extends 


diskit . SphereCutterSensor 


{ 


9  /*  inherited  parameter  diskit .Mover3D  mover  */ 

10  /*  inherited  parameter  double  maxRange  */ 

11  private  double  SL; 

12  private  double  DI; 

13  private  simkit .random. RandomVariate  RD; 

14  private  diskit . SonarScan  scans; 

15  private  double  pinglnterval; 

16  private  simkit .random. RandomVariate  noise; 

17  private  double  frequency; 

18 

19  protected  double  TL; 

20  protected  double  TS; 

21  protected  double  DT; 

22  protected  double  NL; 

23  protected  double  AT; 

24  protected  java. util .Hashtable  detections  =  new  java. util .Hashtable () 

25 

26  /**  Creates  a  new  instance  of  MultiLRATLSonar  */ 

27  public  MultiLRATLSonar (diskit .Mover3D  mover, 

28  double  maxRange, 

29  double  SL, 

30  double  DI, 

31  simkit . random. RandomVariate  RD, 

32  diskit . SonarScan  scans, 

33  double  pinglnterval, 

34  simkit . random. RandomVariate  noise, 

35  double  frequency)  { 

36 

37  super (mover, maxRange) ; 

38  setSL(SL); 

39  setDI(DI); 

40  setRD(RD); 

41  setScans (scans) ; 

42  setPinglnterval (pinglnterval) ; 

43  setNoise (noise) ; 

44  setFrequency (frequency)  ; 

45  } 

46 

47  /**  Set  initial  values  of  all  state  variables  */ 

48  public  void  reset ()  { 

49 

50  super . reset  () ; 

51 

52  /**  StateTransitions  for  the  Run  Event  */ 

53 

54  DT  =  RD . generate  () ; 

55  } 

56 

57  public  void  doRun()  { 

58  super .doRun () ; 

59  firePropertyChange ("DT", DT) ; 

60  if  (true)  { 

61  waitDelay ("RegisterSensor",  0 . 0, new  Object [] {this },  0) ; 

62  } 

63 

64  } 

65 
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public  void  doCheckDetection (diskit .Mover3D  contact)  { 
diskit. Vec3d  relativeLocation  =  (diskit .Vec3d) new 
diskit. Vec3d (contact. getLocation ( ) )  ; 
relativeLocation . sub (getMover ( ) . getLocation ( ) ) ; 
diskit. Vec3d  relativeVelocity  =  (diskit .Vec3d) new 
diskit. Vec3d (contact. getVelocity ( )  )  ; 
relativeVelocity . sub (getMover ( ) . getVelocity ()); 
java. util .Vector  intercepts  = 

(java. util .Vector) scans . intercept (relativeLocation, relativeVelocity) ; 

/*  Code  insertion  for  Event  CheckDetection  */ 

System. out .println (">>>>>>>Checking  detection  of  "+contact); 

System,  out  .println  ( "»»»>Intercepts  at  "+intercepts+"  length 
"+intercepts . size () ) ; 

/*  End  Code  insertion  */ 

/*  StateTransition  for  detections  */ 

java.util.Hashtable  _old_Detections  =  get Detect ions  () ; 
detections .put (contact,  new  Boolean (false) ) ; 

firePropertyChange ("detections",  _old_Detections,  getDetections () ) ; 


if 


} 


} 


(intercepts . size ( )  >  0)  { 

waitDelay ("Processlntercepts", 0.0, new  Object!] (intercepts, new 
Integer ( 0 ) , contact } , 0 ) ; 


public  void  doStartPings (diskit .Mover3D  contact,  diskit. Vec4d  enterPoint, 
diskit. Vec4d  exitPoint)  { 

/*  Code  insertion  for  Event  StartPings  */ 

System,  out  .println  (">>>»>>>Starting  pings  ..."); 

/*  End  Code  insertion  */ 


if  (true)  { 

waitDelay ("Ping", 0 . 0, new  Object [ ] {contact} , 0) ; 

} 


public  void  doPing (diskit .Mover3D  contact)  { 
double  range  = 

(double) Vec3d. distance (getMover ( ) . getLocation ( ) , contact . getLocation ( ) ) ; 
double  fSq  =  (double) frequency*f requency; 

/*  Code  insertion  for  Event  Ping  */ 

System,  out  .println  ("»»»>>Ping  to  range  "+range)  ; 

/*  End  Code  insertion  */ 

/*  StateTransition  for  TL  */ 
double  _old_TL  =  getTLQ; 

TL  =  10  *  Math. log (range) ; 

firePropertyChange  ("TL",  _old_TL,  getTLO); 

/*  StateTransition  for  DT  */ 
double  _old_DT  =  getDT(); 

DT  =  getRD().generate(); 

firePropertyChange  ("DT",  _old_DT,  getDTO); 

/*  StateTransition  for  TS  */ 
double  _old_TS  =  getTSO; 

TS  =  -15.0; 

firePropertyChange  ("TS",  _old_TS,  getTSO); 

/*  StateTransition  for  NL  */ 
double  _old_NL  =  getNL(); 

NL  =  noise.generateO; 

firePropertyChange  ("NL",  _old_NL,  getNLO); 

/*  StateTransition  for  AT  */ 
double  _old_AT  =  getAT(); 

AT  =  (range/1000.0)  *  (.003  +  ( . l*fSq/ (1+fSq)  )  +  (40 . 0*fSq/ (4100 . 0  +  fSq)  ) 
+  . 000275*fSq)  *  12.0/11.0; 
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/*  Code  block  for  pre-transition  */ 

System. out. println ("SL:  "+SL+"  TL:  "+TL+"  TS :  "+TS+"  NL :  "+NL+"  DI 
DT:  "+DT+"  AT:  "+AT+" \nSL- ( 2 *TL) +TS- (NL-DI ) -DT-AT  =  "+(SL-(2*TL) 
(NL-DI ) -DT-AT) ) ; 

firePropertyChange  ("AT",  _old_AT,  getATO); 
if  (true)  { 

waitDelay ( "Ping" , getPinglnterval ( ) , new  Object [ ] {contact} ,  0)  ; 

} 

if  ( (  (SL  -  (2  *  TL)  +  TS  -  (NL-DI  )  -  DT  -  AT)  >0.0)  &&  (!  ( 

(  (Boolean)  (detections . get (contact) )  ) .booleanValue ( ) ) ) )  { 
waitDelay  ("Detection", 0 . 0, new  Object [] {contact} , 0) ; 

} 

if  ( (  (SL  -  (2  *  TL)  +  TS  -  (NL-DI  )  -  DT  -  AT)  <=  0.0)  &&  (( 

(  (Boolean)  (detections . get (contact) )  ) .booleanValue ())) )  { 
waitDelay ( "UnDetection" , 0 . 0, new  Object [ ] {contact} , 0) ; 

} 

} 

public  void  doStopPings (diskit .Mover3D  contact)  { 

/*  Code  insertion  for  Event  Stoppings  */ 

/*  End  Code  insertion  */ 

if  (true)  { 

interrupt ("Ping", new  Object [] {contact} ) ; 

} 

waitDelay ( "UnDetection", 0 . 0, new  Object [ ] { } , 0 . 0) ; 


public  void  doDetection (diskit .Mover3D  contact)  { 

/*  Code  insertion  for  Event  Detection  */ 

System. out . println ( "MultiLRATLSonar  "+this+"  Detected  "+contact) ; 

/*  End  Code  insertion  */ 

/*  StateTransition  for  detections  */ 

java.util.Hashtable  _old_Detections  =  get Detect ions ()  ; 
detections .put (contact, new  Boolean (true) ) ; 

firePropertyChange ("detections",  _old_Detections,  getDetections  () ) ; 


} 

public  void  doUnDetection (diskit .Mover3D  contact)  { 

/*  Code  insertion  for  Event  UnDetection  */ 

System. out .println ("UnDetection  "+contact) ; 

/*  End  Code  insertion  */ 

/*  StateTransition  for  detections  */ 

java.util.Hashtable  _old_Detections  =  getDetections  () ; 
detections .put (contact, new  Boolean ( false) ) ; 

firePropertyChange ("detections",  _old_Detections,  getDetections ()  )  ; 


} 

public  void  doProcessIntercepts (java . util .Vector  intercepts,  int  count, 
diskit .Mover3D  contact)  { 

diskit. Vec4d[]  intercept  =  (diskit .Vec4d []) (diskit .Vec4d [] ) 
(intercepts . get (count) ) ; 

/*  Code  insertion  for  Event  Processlntercepts  */ 

System,  out  .println  ("»»>»»Intercept  0  ”+intercept[0]); 

System,  out  .println  ("»»»»>Intercept  1  "+intercept  [1]  )  ; 

/*  End  Code  insertion  */ 


if 


} 

if 

} 

if 


(count  <  intercepts . size ()  -  1)  { 

waitDelay ("Processlntercepts", 0.0, new  Object [] { intercepts, new 
Integer (count+1) , contact} ,0); 

(intercept [1] . get  (3)  >  0.0)  { 

waitDelay ("Stoppings", intercept [1] .get (3) ,new  Object [] {contact} 
(intercept [1] .get (3)  >  0.0  )  { 
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waitDelay ("StartPings", intercept [0] .get (3) >0 . 0?intercept [0] .get (3) : 0.0, new 
Object [] {contact, intercept [0] , intercept [1] } , 0) ; 

} 

} 

public  void  doRegisterSensor (diskit . Sensor  sensor)  { 

/*  Code  insertion  for  Event  RegisterSensor  */ 

/*  End  Code  insertion  */ 


} 

public  void  setSL  (double  SL)  { 
this . SL  =  SL; 

} 

public  double  getSL()  { 
return  SL; 

} 

public  void  setDI (double  DI)  { 
this . DI  =  DI; 

} 

public  double  getDI ()  { 
return  DI; 

} 

public  void  setRD (simkit . random. RandomVariate  RD)  { 
this . RD  =  RD; 

} 

public  simkit . random. RandomVariate  getRD()  { 
return  RD; 

} 

public  void  setScans (diskit . SonarScan  scans)  { 
this. scans  =  scans; 

} 

public  diskit .  SonarScan  getScansO  { 
return  scans; 

} 

public  void  setPinglnterval (double  pinglnterval)  { 
this .pinglnterval  =  pinglnterval; 

} 

public  double  getPinglnterval ( )  { 
return  pinglnterval; 

} 

public  void  setNoise (simkit .random. RandomVariate  noise)  { 
this. noise  =  noise; 

} 

public  simkit .  random.  RandomVariate  getNoiseO  { 
return  noise; 

} 

public  void  setFrequency (double  frequency)  { 
this . frequency  =  frequency; 

} 

public  double  getFrequency ()  { 
return  frequency; 

} 

public  double  getTL()  { 
return  TL; 

} 
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public  double  getTS ()  { 
return  TS; 

} 

public  double  getDT()  { 
return  DT; 

} 

public  double  getNL()  { 
return  NL; 

} 


public  double  getAT()  { 
return  AT; 

} 

public  java. util .Hashtable  getDetections ( )  { 

return  (java . util . Hashtable)  detections . clone () ; 

} 


/*  Inserted  code  for  MultiLRATLSonar  */ 
/* 


Some  Frequencies  of  interest 


3.5  kHz 
10  kHz 
30  kHz 
60  kHz 
100  kHz 


.22  db/kyd  (.24  db/km) 

1.08  db/kyd  (1.19  db/km) 
7.55  db/kyd  (8.31  db/km) 
19.79  db/kyd  (21.77  db/km) 
31.22  db/kyd  (34.34  db/km) 


*/ 


public  static  double  FREQ_3_5_Khz  =  3.5000; 
public  static  double  FREQ_10_Khz  =  10.0000; 
public  static  double  FREQ_30_Khz  =  30.0000; 
public  static  double  FREQ_60_Khz  =  60.0000; 
public  static  double  FREQ_100_Khz  =  100.0000; 
/*  End  inserted  code  */ 


As  can  be  seen  from  the  above  code,  the  Sensor  derives  its  sense  of  location  from  a 
Mover  that  it  has  been  mounted  on,  and  that  it  is  irrelevant  whether  or  not  the  mounting  point  is 
stationary  or  moving. 

The  following  Viskit  Assembly  scenario,  IndianlslandSonarTest ,  mounts  an  unmanned 
MultiLRATLSonar  to  a  stationary  AmmoPier.  Since  manned  SMAL  entities  use  the  abstract 
Sensor ,  they  easily  mount  with  a  MultiLRATLSonar  and  respond  to  obstacles  and  other  objects  in 
the  same  way,  however  this  example  for  simplicity  is  stationary  and  causes  no  response  within 
the  scenario. 
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Figure  20.  Adding  the  MultiLRATLSonar  as  a  drop  in  component. 


The  scenario  is  now  ready  to  run.  Below  shows  a  sample  run  of  IndianlslandSonarTest 
within  Viskit’s  Assembly  Runner.  The  output  debug  messages  shown  are  ordinarily  disabled, 
but  are  demonstrative  of  the  FOM  determining  Detection  and  UnDetection  events,  as  entities 
traverse  the  MultLRATLSonar's  detection  zone,  and  in  particular,  two  such  entities,  one  of  which 
momentarily  becomes  detectable. 
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v  Viskit  Assembly  Runner:  atfp.IndianIslandSonarTest 

File  Edit  Help 

Event  Graph  Editor  Assembly  Editor  Assembly  Run  Analyst  Report 

Local  Run  \  H  Design  of  Experiments  \  ffl  LaunchCluster  Job 


_  n  x 


Sim  start  time:  571.9397 
Sim  stop  time: 

#  replications: 


1000.0 


□  Verbose  output 
0  Save  replication  data 
0  Print  replication  reports 
0  Print  summary  reports 


POSTGRADUATE 

SCHOOL 


»»»»Ping  to  range  3425.0760640221183 
SL:  226.0  TL:  81.38878958923331  TS:  -15.0  NL:  -5.512726300632674  DI  15. d 
SL-(2*TL)+TS- (NL-DI) -DT-AT  =  29.51936650490538 
»»»»Ping  to  range  4777.972532214294 

SL:  226.0  TL:  84.7177157906519  TS:  -15.0  NL:  -9.905030937730254  DI  15.0 
SL- (2*TL)+TS- (NL-DI) -DT-AT  =  15.88333433651811 
Multi LRATLSonar  Multi LRATLSonar  [6000.0] 

DISEntity:  Entity  ID#  800  at  (-343.347,-1178.404,-47.074) 
startPositi on  (-343. 347, -1178.404,-47.074) 
desti nati on  (-343. 347, -1178.404,-47.074) 
velocity  (0.0, 0.0, 0.0)  cruisingSpeed  0.0 

Detected 

DISEntity:  Entity  ID#  600  at  (3986.9313651711127,840.38148569412 
startPositi on  (8432. 380424058734, 755.6260894936363,0.0) 
desti nati on  (3604 . 025806177327 , 847 . 6818308178663 , 0 . 0) 
vel oci ty  (-24 . 99545749855312 , 0 . 4765547586844846 ,0.0)  c rui si ngSpt 


»»»»Ping  to  range  3375.7358265057837 
SL:  226.0  TL:  81.24368602211521  TS:  -15.0  NL:  3.6789631634817987  DI  15. d 
SL-(2*TL)+TS- (NL-DI) -DT-AT  =  20.599447346880936 
»»»»Ping  to  range  4733.119543237842 
SL:  226.0  TL:  84.62339786979604  TS:  -15.0  NL:  -5.950394944300552  DI  15. C 
SL-(2*TL)+TS- (NL-DI) -DT-AT  =  14.809278927184955 
»»»»Ping  to  range  3326.415292228578 
SL:  226.0  TL:  81.09650514323995  TS:  -15.0  NL:  -0.16813378393304404  DI  1^ 
SL-(2*TL)+TS- (NL-DI) -DT-AT  =  27.10515977091876 
»»»»Ping  to  range  4688.3706874100435 

SL:  226.0  TL:  84.5284039967737  TS:  -15.0  NL:  8.426848710571575  DI  15.0 
SL-(2*TL)+TS- (NL-DI) -DT-AT  =  -1.1269963977957431 
UnDetection 

DISEntity:  Entity  ID#  600  at  (3886.9495351769,842.2877047288634, 
startPositi on  (8432. 380424058734, 755.6260894936363,0.0) 
desti nati on  (3604 . 025806177327 , 847 . 6818308178663 , 0 . 0) 
vel oci  ty  (-24 . 99545749855312 , 0 .4765547586844846 ,0.0)  c  rui si ngSpt 


»»»»Ping  to  range  3277.1153507909326 
SL:  226.0  TL:  80.94718848198602  TS:  -15.0  NL:  1.9478910447429527  DI  15. d 
SL-(2*TL)+TS- (NL-DI) -DT-AT  =  23.772901921941614 
»»»»Ping  to  range  4643.72897513964 
si  •  n  TI  •  Bd  437 7?aangq«vm  ts-  -is  n  mi  •  -is  nRSQdn^smnqq  nt  IS 


Figure  2 1 .  Debug  Output  from  a  Random  Run  of  IndianlslandSonarTest  in  Viskit. 
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APPENDIX  F:  PLANET  9  PRESENTATION  SLIDESETS 


F.l  INTRODUCTION 

These  presentations  were  originally  give  during  the  May  M&S  Workshop  here  at  NPS  by 
Christian  Greuel  and  David  Colleen.  They  are  reprinted  here  by  permission  of  the  Planet  9 
Studios  Art  Team  and  are  relevant  to  the  processes  required  to  building  port  and  shore  side 
installation  models. 


103 


F.l  BUILDING  GEO-REGISTERED  X3D 


Goal  of  This  Presentation 


This  presentation  will  provide  a  high-level  overview 
of  the  production  process  used  by  Planet  9  Studios 
to  create  high-fidelity  geo- referenced  X3D  models 
of  waterside  facilities  for  the  WSS  AT/FP  Project. 


Activities  Modeled  for  US  Navy 

Al-Basrah  Oil  Terminal  (ABOT) 

Friday  Harbor 

MCAS  Miramar 

NAS  North  Island  (rough) 

NAVMAG  Indian  Island 

NAVSTA  Bremerton 

Pearl  Harbor 

Port  Hueneme  (rough) 

SUBASE  Bangor 

Washington  Navy  Yard 

Yokosuka,  Japan 

Activities  Modeled  for  WSS  AT/FP 


Al-Basrah  Oil  Terminal  (ABOT) 


NAVMAG  Indian  Island 
NAVSTA  Bremerton 
Pearl  Harbor 


Activities  Modeled  for  Other  Govt. 


Ft.  Benning  -  McKenna  MOUT 
Ft.  Campbell  -  Cassidy  MOUT 
Ft  Dix  -  Range  65 
Ft.  Lewis  -  Leschi  MOUT 
Ft.  Polk  -  Self  Airbase 
George  AFB  (now  SCLA) 

MCAS  Miramar 
Moffett  Field  (NASA) 

Nellis  AFB 
Peterson  AFB 
Puhakuloa  Training  Area 


Tools  Used 


Many  excellent  tools  exist.  Our  production  pipeline 
makes  use  of  the  following: 

•  Global  Mapper  -  www.aloMlniaaaei .mm 

•  3D  Studio  Max  —  www.dscreet.com 

•  PolyTrans  -  www.ofano.com 

•  VrmIPad  -  MauanMaiaabiaguii 

•  Chisel  -  http://www2.hro.no/vr/toob/diisel/in5tal1.htm 

•  X3D-Edit  -  hm://rrwn.webjd.arB/>3d'cpmeil/RLiV2HEJQD-Ed!t.ht;n1 

•  Xj3D  -  http://www.web3d.orti/x3d/applicapon5/xj3d/ 
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□  0  □  D  B-EHD  3! 

J.  I  .  w 


Production  Pipeline 


Production  Pipeline 


Collect  Data 

O  D 

•  Terrain:  DEM,  DTED2,  Contours 

•  Imagery:  MrSID,  GeoTIFF 

•  CAD  Drawings:  DXF,  DWG 

•  GIS  Data:  ESRI,  ERDAS,  etc. 

a-osi-E 

•  Bathymetry:  Contours,  Soundings 

•  Photos:  JPEG 

H 

a 

1 

i 

a 

E3 

a 
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D1BD0QD 


Data  Sources 


Import  Terrain  — ►  Global  Mapper 


•  USGS 
-  NGA 

•  NFESC 

•  NAVSEA  Warfare  Centers  Division 

•  GeoReadiness  Repository  (GRR) 

•  Navy  Region  GIS  Center  of  Excellence 

•  Local  Base:  Engineering  Division 

•  Commercial  (Space  Imaging,  etc.) 

•  Internet  (beware  copyright.  Ref.  only) 
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DDDDB« 


Zoom  to  Building  Level 


Reference  Photos 
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BD-fl-DDDD 

LflIJ 


Edit  VRML  File  (ASCII) 


•  VRML  specific  text  editor 

•  Add  Inlines  (Ext  References) 

•  Add  Navigationlnfo 

•  Route  Cameras  to  Nav  Type 

•  Add  Background  (Skybox) 

•  Remove  Unused  Identifiers 

•  Search/Replace  URL  paths 

•  Error  Checking 

•  Misc.  Manual  Edits 
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Edit  VRML  in  Chisel 


.  i 

H  □ 

• . E3 

i 
i 


Further  optimization 
Create  USE/DEF  (instancing) 
Remove  Material  nodes 
Remove  Useless  nodes 
Remove  Default  fields 


rlmttt* 
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F.2  3D  GEOSPATIAL  DATA  INTERFACES  AND  TOOLS 


3D  Geospatial  Data 
Interfaces  &  Tools 


David  Colleen,  CEO 
Planet  9  Studios 
San  Francisco  &  Orlando 
www.planec9.com 


Alex  Viana: 


NAVFAC  Project  Goals 


“The  Naval  Facilities  Engineering  Service  Center  (NFESC)  began  a  pilot  project  in  1996  to 
evaluate  if  web  based,  virtual  3D  geo-spatial  waterfront  facility  models  could  be  useful  as 
training  aids,  and  computer  graphical  user  interfaces  to  facility  information  management 
databases.  These  efforts  undertaken,  in  general,  support  the  Office  of  the  Secretary  of 
Defense's  strategic  goals  for  the  DoD's  Infrastructure  Information  Environment: 

■Improve  awareness:  Inform  real  property  professionals  of  the  importance  of 
accurate  inventories  to  support  planning  and  programming  for  future  requirements. 
•Enhance  access:  Provide  all  potential  Defense  users  real-time  access  to  standardized 
real  property  information. 

•Optimize  resources:  Ensure  that  resources  currently  used  to  transfer  and  transform 
data  are  enhanced  or  reduced  and  redirected  to  improve  maintenance  and  acces  si  bitty  of 
data. 

All  work  has  been  performed  using  open  source,  ISO  based  standards,  and  has  been 
conducted  in  partnership  with  the  private  sector  (Planet  9  Studios),  academia  (Naval 
Postgraduate  School),  and  other  Governmental  Agencies  (National  Institutes  of  Standards 
and  Technology).  We  believe  that  the  results  of  our  efforts  may  be  a  useful  process  for 


■N/VfiAC 


An  Open  Approach 


Tools  of  the  Trade 


Tools  That  We  Use: 

•AutoDesk's  AutoCAD 
•3D  Studio  Max 
•Global  Mapper 
•Chisel 

•Parallel  Graphics'  VRMLpad 


QN/VnOC 


NAfRAC 
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Data  Transformation  Process 


Data  Transformation  Process 

Step  Four  -  Import  waterfront  facilities  VRML  fie  Into  Chisel  for 
restructuring  then  translate  to  X3D  Customize  HTML  user  interface 
with  external  data  links 


Virtual  Pearl  Harbor 


The  Pearl  Harbor  BIM  started  as  a  base  redevelopment 
planning  tool.  It  was  next  used  to  develop  renovation  proposals 
for  the  Arizona  Memorial.  This  was  subsequently  used  on  the 
National  Parks  Service  public  web  site  as  a  visitor  orientation 

tool . and  so  on.  The  current  use  of  the  BIM  is  for  port  security 

planning  and  training. 


112 


Lessons  Learned 


Existing  AutoCAD  data  can  be  translated  into  open, 
interoperable  formats.. 

Evolution... not  revolution. 

Project  pre-planning  saves  time  later. 

Work  done  in  open  standards  still  works. 


1 


NA/FiAC 
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Other  Related  Projects 


Army  Landwarrior  &  Boeing 
IB-CSAS  Programs 


Army  FBCB2 
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APPENDIX  G:  PHASE  II  TECHNICAL  SUMMARY  OF  X3D  MODEL 

CONSTRUCTION 


G.l  PLANET  9  STUDIOS  ART  TEAM 
Overview 

In  February  2006,  Planet  9  Studios  received  a  scope  of  work  (SOW)  for  Phase  II  of  the 
Modeling  and  3D  Visualization  for  Evaluation  of  Anti-Terrorism/Force  Protection  (AT/FP) 
Alternatives.  The  major  portion  of  the  SOW  included  the  development  of  Extensible  3D  (X3D) 
models  of  waterside  buildings  and  underlying  terrain  at  Pearl  Harbor,  Hawaii.  This  technical 
summary  documents  important  attributes  of  these  models,  including  naming  conventions  and 
hierarchical  organization,  which  will  be  useful  for  understanding  their  structure  and  use. 


Terrain 

A  geo-referenced  X3D  terrain  model  of  Oahu  was  developed  from  10-meter  Spatial  Data 
Transfer  Standard  (SDTS)  Digital  Elevation  Model  (DEM)  files.  This  source  data,  originating 
from  the  U.S.  Geological  Survey  (USGS),  was  obtained  at  no  cost  from  the  publicly  available 
GeoCommunity™  website  (www.geocomm.com).  A  total  of  sixteen  individual  quads 
comprising  Honolulu  County  were  required  for  complete  coverage  of  the  island.  These  quads 
were  Haleiwa,  Hauula,  Honolulu,  Kaena,  Kaena  OE  W,  Kahana,  Kahuku,  Kaneohe,  Koko  Head, 
Mokapu,  Pearl  Harbor,  Scholfield  Barracks,  Waianae,  Waimea,  and  Waipahu. 

The  individual  quads  were  combined  with  Global  Mapper  software,  a  geographic  data 
viewer  and  format  converter.  The  dataset  was  then  re-projected  into  the  Universal  Transverse 
Mercator  (UTM)  coordinate  system  with  the  following  attributes: 

Projection:  UTM 

Zone:  4 

Datum:  WGS84 

Planar  Units:  Meters 
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This  projection  has  two  basic  benefits.  First,  UTM  is  defined  within  Cartesian  XYZ 
space,  which  is  the  same  as  that  in  which  the  3D  models  are  authored.  Second,  it  uses  meters  as 
its  planar  unit,  which  is  the  same  unit  of  measure  used  by  X3D. 

The  combined  elevation  model  of  Oahu,  measuring  75x60  km,  was  exported  as  a  single 
DEM,  re-sampled  at  a  500-meter  resolution.  The  Pearl  Harbor  area  (10x10  km),  being  the  area  of 
interest,  was  exported  separately  at  a  higher  resolution  of  50-meters.  These  new  DEMs  were 
imported  into  the  3D  authoring  tool,  Autodesk  3dsmax,  with  the  UTM  coordinate  (608354.00, 
2362714.00,  0.00)  being  centered  at  its  local  XY  origin  (0,  0,  0).  To  the  immediate  area  around 
Pearl  Harbor,  topographic  data  was  integrated  into  the  greater  terrain  model  for  further 
refinement. 

The  terrain  models  were  each  divided  into  separate  sections  along  a  regular  grid.  This 
allows  for  efficient  view  frustum  culling  as  well  as  the  implementation  of  Level  of  Detail  (LOD) 
switching.  The  Oahu  terrain  was  divided  into  a  5x4  grid,  with  each  section  measuring  15x15  km. 
The  higher-resolution  Pearl  Harbor  terrain  was  divided  into  an  octagonal  4x4  grid,  with  each 
section  measuring  2500x2500  meters.  Each  of  these  grid  sections  was  then  optimized  by  utilizing 
a  polygon  reduction  modifier,  automatically  substituting  larger  triangles  for  continuous  areas  of 
the  terrain  mesh  that  were  co-planar  within  an  acceptable  threshold. 


Figure  22.  Oahu  and  Pearl  Harbor  Terrain  Grids  Optimized 
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Figure  23.  Oahu  and  Pearl  Harbor  Terrains  Drapped  with  Imagery 


The  Oahu  terrain  mesh  was  draped  with  color-corrected  30-meter  Land  Remote-Sensing 
Satellite  (LANDS AT)  imagery.  This  higher-resolution  Pearl  Harbor  area  was  draped  with  1- 
meter  imagery  originating  from  Space  Imaging.  This  area  included  the  Naval  Station,  Naval 
Shipyard,  SUBASE,  FISC,  and  Ford  Island  facilities.  The  resulting  geometry  was  then  optimized 
for  real-time  rendering,  including  the  addition  of  Levels  of  Detail  (LOD)  for  increased 
efficiency,  and  geo-referenced  within  the  Universal  Transverse  Mercator  (UTM)  coordinate 
system  as  described  in  the  X3D  Geospatial  specification. 


Figure  24.  Oahu  and  Pearl  Harbor  Terrain  Grids  Designated 
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Given  its  low  resolution,  the  entire  Oahu  terrain  was  able  to  be  saved  as  a  single  X3D 
file,  complete  with  the  exception  of  the  inlined  octagonal  Pearl  Harbor  area  (see  below). 
However,  the  Oahu  terrain  file  does  have  five  different  versions,  each  named  with  a  convention 
of  “Terrain* .  x3d”,  where  “*”  identifies  which  version(s)  of  the  Pearl  Harbor  terrain  are  to  be 
inlined.  Thus  the  file  selected  from  one  of  the  following  five  becomes  the  master  terrain  file: 


Terrain . x3d 

Oahu  terrain;  inlines  16  Pearl  Harbor  sections  under  GeoLODs: 

PearlHarborTerrain<col><row>High . x3d 
PearlHarborTerrain<col><row>Low . x3d 

TerrainHigh . x3d 

Oahu  terrain;  inlines  16  Pearl  Harbor  sections: 

PearlHarborTerrain<col><row>High . x3d 

TerrainMed . x3d 

Oahu  terrain;  inlines  16  Pearl  Harbor  sections: 

Pear lHarborTerrain<col><row>Med . x3d 

TerrainLowPiers . x3d 

Oahu  terrain;  inlines  16  Pearl  Harbor  sections: 

PearlHarborTerrain<col><row>LowPiers . x3d 

TerrainLow . x3d 

Oahu  terrain;  inlines  16  Pearl  Harbor  sections: 

PearlHarborTerrain<colXrow>Low .  x3d 

Table  3.  Various  Resolution  Version  of  the  Oahu  Terrain 


Within  each  version  of  the  “Terrain* .  x3d”  files  are  two  Group  nodes.  The  group 
“oahuTerrain”  contains  each  of  the  twenty  grid  sections  of  the  greater  Oahu  terrain.  Each  grid 
section  is  individually  named  with  a  convention  of  “gnd_Oahu<colxrow>”,  where  “gnd_” 
identifies  the  object  as  ground,  “<coi>”  is  a  grid  column  letter  from  A-E  starting  from  the  left, 
and  “<row>”  is  a  grid  row  number  from  1-4  starting  from  the  top.  Thus,  the  individual  grid 
sections  of  Oahu  are  named  as  follow: 


gnd  OahuAl 

gnd  OahuBl 

gnd_OahuCl 

gnd  OahuDl 

gnd  OahuEl 

gnd  OahuA2 

gnd  OahuB2 

gnd  OahuC2 

gnd  OahuD2 

gnd  OahuE2 

gnd  OahuA3 

gnd  OahuB3 

gnd  OahuC3 

gnd  OahuD3 

gnd  OahuE3 

gnd  OahuA4 

gnd  OahuB4 

gnd_OahuC4 

gnd  OahuD4 

gnd  OahuE4 

Table  4.  Individual  Grid  Sections  of  the  Oahu  Terrain 


Under  the  second  group,  “PeariHarborTerrain”,  each  of  the  external  Pearl  Harbor 
terrain  grid  section  files  is  called.  This  is  done  via  the  X3D  “GeoLOD”  node,  thereby  allowing  for 
LOD  switching  if  desired. 
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The  sixteen  Pearl  Harbor  grid  sections  were  each  saved  as  individual  X3D  files  named 
with  a  convention  of  “PearlHarborTerrain<col><row>*  .x3d”,  where  “<col>”  is  a  grid 
column  letter  from  A-D  starting  from  the  left,  “<row>”  is  a  grid  row  number  from  1-4  starting 
from  the  top,  and  identifies  the  resolution  of  the  terrain  imagery.  Note  that  the  resolution 
component  of  these  file  names  correspond  to  those  of  the  master  “Terrain*  .x3d”  files,  which 
call  them  (see  above).  Example  file  names  for  the  single  Pearl  Harbor  grid  section  “ai”  are  as 
follow: 


PearlHarborTerrainAlHigh . x3d 

Pearl  Harbor  section  Al,  with  High-Res  2048x2048 
Terrain  imagery.  Includes  Pier  geometry. 

Pear lHarborTerrainAlMed . x3d 

Pearl  Harbor  section  Al,  with  Medium-Res 

1024x1024  Terrain  imagery.  Includes  Pier  geometry. 

PearlHarborTerrainAlLowPiers . x3d 

Pearl  Harbor  section  Al,  with  Low-Res  512x512 
Terrain  imagery.  Includes  Pier  geometry. 

PearlHarborTerrainAlLow . x3d 

Pearl  Harbor  section  Al,  with  Low-Res  512x512 
Terrain  imagery.  DOES  NOT  include  Pier  geometry. 

Table  5.  Example  File  Names  for  the  Single  Pearl  Harbor  Grid  Section  Al 

Each  Pearl  Harbor  terrain  grid  section  has  four  different  LOD  resolutions.  These  are 
differentiated  not  by  geometry,  but  rather  by  the  resolution  of  the  texture  map  applied  to  each. 
The  high  resolution  texture  maps  are  each  2048x2048  pixels  in  size.  The  medium  resolution 
texture  maps  are  1024x1024  pixels  in  size.  The  low  resolution  texture  maps  are  512x512  pixels 
in  size.  The  one  case  of  reduced  geometric  resolution  is  in  those  sections  named 
“peariHarborTerrain<coi><row>Low .  x3d”,  in  which  the  piers  have  been  removed  for 
increased  performance  when  needed. 

The  texture  maps  for  the  terrain  files  are  located  in  subdirectories  of  the  Textures 
directory.  The  three  numbered  subdirectories  contain  the  texture  maps  for  the  section  grids  of  the 
various  terrain  resolutions:  High  (2048),  Medium  (1024),  and  Low  (0512).  Note  the  use  of  the 
leading  zero  for  the  three-digit  number.  The  Oahu  subdirectory  contains  the  texture  maps  for  the 
section  grids  of  the  greater  Oahu  terrain.  Finally,  the  Wharfs  subdirectory  contains  texture  maps 
for  the  various  piers  and  wharfs. 
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Buildings 

Atop  the  terrain  were  constructed  geo-referenced  X3D  models  of  the  majority  of  Navy 
buildings  visible  from  the  water,  as  well  as  piers  and  wharves  attached  to  the  facilities.  The  piers 
and  wharves  are  part  of  the  terrain  files  (see  above).  The  location  and  footprint  of  each  structure 
was  extracted  from  the  provided  computer-aided  drafting  (CAD)  files,  which  had  been  manually 
rectified  to  the  geo-referenced  terrain.  The  footprints  were  then  extruded  and  the  resulting 
geometry  modified  to  create  a  representational  3D  model  of  each  structure.  To  these  were 
applied  texture  maps  which  were  derived  from  the  location  photographs,  thereby  resulting  in  a 
photo-realistic  model  for  use  in  the  AT/FP  simulation  software. 


Figure  25.  Pearl  Harbor  Buildings  Grouped  into  Five  Separate  Files  Determined  by  Location. 


For  ease  of  management,  the  buildings  were  grouped  into  five  separate  files  determined 
by  their  location.  These  areas  are  Ford  Island,  Ford  Island  Bridge,  Naval  Shipyard,  Naval  Station 
(comprised  of  NAVSTA,  SUBASE,  and  FISC),  and  Extra  Buildings  (outlying  area  amongst  and 
beyond  the  lochs).  Furthermore,  each  of  these  five  files  is  available  with  two  different  resolutions 
of  texture  maps  applied.  The  high  resolution  version  is  identified  simply  as  the  name  of  the 
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location  (e.g.  Fordisiand.x3d).  The  low  resolution  version  appends  the  word  “low”  to  the  file 
base  name  (e.g.  FordisiandLow.x3d) 

In  turn,  the  appropriate  resolution  of  these  five  location  files  is  called  by  one  of  five 
master  building  files.  These  go  by  the  naming  convention  of  “Building* .  x3d”,  where  “*” 
identifies  which  version  of  the  building  locations  are  to  be  inlined.  Additionally,  the  master 
building  file  will  also  call  one  of  the  previously  discussed  master  terrain  files.  Thus  the  file 
selected  from  one  of  the  following  five  becomes  the  overall  master  file. 


Buildings .x3d 

High-Res  Building  files  inlined;  Terrain  inlined  via: 

Terrain . x3d 

Bui 1 dings High . x3d 

High-Res  Building  files  inlined;  Terrain  inlined  via: 

TerrainHigh . x3d 

BuildingsMed . x3d 

High-Res  Building  files  inlined;  Terrain  inlined  via: 

TerrainMed. x3d 

BuildingsLowPiers . x3d 

Low-Res  Building  files  inlined;  Terrain  inlined  via: 

TerrainLowPiers . x3d 

Buildings Low . x3d 

Low-Res  Building  files  inlined;  Terrain  inlined  via: 

TerrainLow . x3d 

Within  each  location  file  (e.g.  Fordisiand.x3d)  reside  the  individual  building  models. 
Each  building  is  situated  underneath  its  own  Transform  node.  Whenever  possible,  this  Transform 
node  is  named  for  its  designated  building  number  as  identified  on  the  provided  CAD  drawings. 
The  naming  convention  for  the  buildings  then  becomes  “bid_<num>”,  where  “bid  ”  identifies 
the  object  as  a  building,  and  “<num>”  is  the  designated  number  of  the  building.  In  cases  where  a 
building  number  was  not  to  be  found  in  the  CAD  drawings,  a  unique  number  was  assigned  to  it. 

Furthermore,  clusters  of  buildings  in  close  proximity  to  each  other  are  grouped  together 
as  blocks  for  more  efficient  scene  culling.  It  should  be  noted  that  these  block  groupings  are  not 
officially  recognized  blocks,  but  rather  chosen  with  spatial  considerations  for  best  performance. 
The  naming  convention  for  the  blocks  is  “bik_<num>”,  where  “bik_”  identifies  the  grouping  as  a 
block,  and  “<num>”  is  a  unique  number  assigned  to  the  block. 

The  texture  maps  for  the  building  files  are  located  in  subdirectories  of  the  Textures 
directory.  First,  they  are  segregated  into  either  the  High  or  Low  subdirectory.  Below  this  there 
are  subdirectories  for  each  of  the  building  locations.  In  general,  the  texture  maps  in  the  Low 
subdirectories  are  50%  of  the  pixel  size  of  those  in  the  High  subdirectories. 
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[Locations ] 

I --  [PearlHarborBuildings  ] 

| —  Buildings .x3d  < —  OVERALL  MASTER  FILE 

| --  Fordlsland . x3d 
|  | —  [Maps] 

I  I—  [High] 

|  | —  [Fordlsland] 

| --  FordlslandBridge . x3d 
|  | —  [Maps] 

|  | —  [High] 

|  | --  [FordlslandBridge] 

| --  NavalShipyard . x3d 

|  | —  [Maps] 

I  I—  [High] 

|  | —  [NavalShipyard] 

I --  NavalStation . x3d 
|  | —  [Maps] 

I  I—  [High] 

|  | —  [NavalStation] 

| --  ExtraBuildings . x3d 
|  |--  [Maps] 

I  I—  [High] 

|  | --  [ExtraBuildings] 

I 

[  . . /PearlHarborTerrain] 

| —  Terrain.  x3d  < —  MASTER  TERRAIN  FILE 

| --  PearlHarborTerrainAlHigh . x3d 
|  | —  [Maps] 

|  |—  [2048] 

| --  PearlHarborTerrainAlLow . x3d 
|  |—  [Maps] 

I  I--  [0512] 

| --  PearlHarborTerrainD4High . x3d 
|  |—  [Maps] 

|  I--  [2048] 

| --  PearlHarborTerrainD4Low . x3d 
|  |—  [Maps] 

I  I--  [0512] 

I --  [Oahu] 

I  —  [Wharfs] 


Figure  26.  Example  Building/Terrain  File  Dependency  Chart 


124 


Aids  to  Navigation 

A  series  of  Aids  to  Navigation  (ATON)  X3D  PROTO  and  X3D  (non-PROTO)  models 
was  produced  to  allow  the  virtual  waterways  to  be  populated  with  charted  marks  as  they  are  in 
the  actual  world.  Each  ATON  model  can  be  positioned  and  oriented  at  precise  locations  within  a 
given  scene.  The  selection  includes  the  following  models: 

•  Danger  Daybeacon  (non-PROTO) 

•  Daybeacon 

•  Light 

•  Lighted  Buoy 

•  Light  Post 

•  Marker  Buoy  (non-PROTO) 

•  Mooring  Buoy  (non-PROTO) 

•  Range  Light 


The  ATON  X3D  PROTO  models  contain  switches  to  allow  assignment  of  a  few  specific 
attributes  such  as  port  (green)  vs.  starboard  (red),  light  on  vs.  light  off,  and  brightness  of  light 
glow.  These  attributes  are  based  upon  International  Hydrographic  Organization  (IHO)  S-57 
(http:  //www.  caris .  com/s-57).  This  standard,  prepared  by  the  IHO  Committee  on 
Hydrographic  Requirements  for  Information  Systems  (CHRIS),  is  for  the  coding  and  exchange 
of  hydrographic  digital  data. 

While  only  a  few  attributes  are  currently  available,  a  comprehensive  system  of  ATON 
X3D  PROTO  models  with  attributes  adherent  to  S-57  is  the  subject  of  a  future  scope  of  work. 
These  would  include  defined  options  such  as  numeric  designation,  types  of  sounds,  and  precise 
light  flashing  characteristics.  The  system  would  also  include  a  more  complete  selection  of  ATON 
types  (e.g.  Cans/Nuns,  Mileboards,  Warning  Markers,  etc.) 
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Following  is  a  list  of  the  ATON  X3D  PROTO  models  that  currently  exist,  along  with 
their  available  attributes  and  options: 


RangeLightPrototype . x3d 

Attribute 

Default 

Option 

LightType 

1 

0=LightOf f , 
l=LightOn, 

2=LightFlashing (Notlmplemented) 

LightGlow 

111 

XYZ  Scale  of  Light  Glow  Effect 

Table  6.  Aids  to  Navigation  X3D  Proto  Models  -  RangeLight 


NOTE:  Range  Light  model  points  due  North  (-Z)  and  its  light  glow  effect  is  only  visible 
from  that  direction.  The  Range  Light  should  be  rotated  into  its  proper  orientation. 


DaybeaconPrototype . x3d 

Attribute 

Default 

Option 

Catlam* 

*Category  of 

Lateral  Marker 

1 

0=None (Unlikely)  , 
l=PortHand (GreenSquare) , 

2=StarboardHand (RedTriangle)  , 

3=Pref erredChannelToStarboard (TopmostBandGreen) , 
4=Pref erredChannelToPort (TopmostBandRed) 

Number 

N/A 

Not  Implemented 

Table  7.  Aids  to  Navigation  X3D  Proto  Models  -  Daybeacon 
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LightPrototype . x3d 

Attribute 

Default 

Option 

Catlam* 

*Category  of 

Lateral  Marker 

1 

0=None (Unlikely)  , 

l=PortHand (GreenSquare)  , 

2=StarboardHand (RedTriangle)  , 

3=Pref erredChannelToStarboard (TopmostBandGreen) , 

4=Pref erredChannelToPort (TopmostBandRed) 

LightType 

1 

0=LightOf f , 
l=LightOn, 

2=LightFlashing (Notlmplemented) 

LightGlow 

111 

XYZ  Scale  of  Light  Glow  Effect 

PileType 

1 

0=NoPile (Unlikely)  , 

l=SinglePile, 

2=MultiPile 

Number 

N/A 

Not  Implemented 

Table  8.  Aids  to  Navigation  X3D  Proto  Models  -  LightPrototype 


LightedBuoyPrototype . x3d 

Attribute 

Default 

Option 

Catlam* 

*Category  of 

Lateral  Marker 

1 

0=None (Unlikely)  , 
l=PortHand (GreenSquare)  , 

2=StarboardHand (RedTriangle)  , 

3=Pref erredChannelToStarboard (TopmostBandGreen) , 

4 =Pref erredChannelToPort (TopmostBandRed) 

LightType 

1 

0=LightOf f , 
l=LightOn, 

2=LightFlashing (Notlmplemented) 

LightGlow 

111 

XYZ  Scale  of  Light  Glow  Effect 

Number 

N/A 

Not  Implemented 

Table  9.  Aids  to  Navigation  X3D  Proto  Models  -  LightedBouyPrototype 


LightPostPrototype . x3d 

Attribute 

Default 

Option 

LightType 

1 

0=LightOf f , 
l=LightOn, 

2=LightFlashing (Notlmplemented) 

LightGlow 

111 

XYZ  Scale  of  Light  Glow  Effect 

Table  10.  Aids  to  Navigation  X3D  Proto  Models  -  LightPostPrototype 
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EXTERNPROTO  RangeLight  [ 

exposedField  SFInt32  LightType 
exposedField  SFVec3f  LightGlow 

] 

"RangeLightPrototype . wrl#RangeLight" 

EXTERNPROTO  Light  [ 

exposedField  SFInt32  Catlam 
exposedField  SFInt32  LightType 
exposedField  SFVec3f  LightGlow 
exposedField  SFInt32  PileType 
exposedField  SFInt32  Number 

] 

"LightPrototype . wrl#Light" 


DEF  RangeLightFront  Transform  { 
translation  0  0  -25 
rotation  010  3.14159  # 

children  [ 

RangeLight  { 

LightType  1  # 

LightGlow  441  # 

} 


DEF  LightPort  Transform  { 
translation  -10  0  25 
children  [ 

Light  { 

Catlam  1 
LightType  1 
LightGlow  222 
PileType  1 


# 

# 

# 

# 


DEF  LightStarboard  Transform  { 
translation  10  0  25 
children  [ 

Light  { 

Catlam  2  # 

LightType  1  # 

LightGlow  222  # 

PileType  2  # 

} 


Rotate  to  face  South 


Light  On 

Glow  effect  scaled  4x  wide  (XY  only) 


Green  (Port) 

Light  On 

Glow  effect  scaled  two  times  (XYZ) 
Single  Pile 


Red  (Starboard) 

Light  On 

Glow  effect  scaled  two  times  (XYZ) 
Multi  Pile 


} 


Figure  27.  Example  ATON  X3D  Code  (VRML  Syntax)  with  One  Range  Light  and  Two  Lights 
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Figure  28.  Example  ATON  X3D  Scene  with  One  Range  Light  (in  distance)  and  Two  Lights 


Compass  Rose 

Planet  9  Studios  was  asked  create  a  2D  Compass  Rose  X3D  PROTO  for  general  direction 
finding,  to  be  displayed  in  a  Heads-Up  Display  (HUD)  manner  over  any  given  X3D  scene.  The 
resulting  model  consists  of  a  texture  mapped  compass  face  which  rotates  in  direct  correlation 
with  the  orientation  of  the  user’s  viewpoint. 

While  the  visual  components  were  complete  with  basic  functionality  in  place,  the  file  was 
not  finished  as  of  the  final  report.  There  remained  an  issue  of  gimbal  lock  in  the  compass 
rotation,  due  to  the  fact  that  it  was  tied  to  the  viewpoint  orientation  via  the  X3D 
“ProximitySensor”  node.  The  visual  artifact  is  not  noticeable  when  the  viewpoint  is  parallel  to 
the  ground,  but  becomes  apparent  when  viewpoint  is  pitched  up  or  down.  It  has  been  suggested 
that  a  quaternion  approach  may  need  to  be  implemented  in  order  to  alleviate  this  issue.  This  has 
been  documented  as  XMSF  Issue  Tracker  Bug  #1009. 
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The  Compass  Rose  X3D  PROTO  includes  two  attributes  which  may  be  assigned  values. 
The  first  is  the  location  offset,  which  defines  the  position  of  the  compass  face  relative  to  the 
center  of  the  user’s  screen.  The  second  attribute  is  the  size,  which  is  the  XYZ  scaling  of  the 
compass  face  default  dimensions. 


CompassRosePrototype . x3d 

Attribute 

Default 

Option 

locationOf f set 

0  0  0 

XYZ  Modified  screen  location 

size 

111 

XYZ  Modified  compass  size 

Table  1 1 .  Compass  Rose  X3D  PROTO  Attributes  and  Options 


EXTERNPROTO  CompassRose  [ 

field  SFVec3f  locationOf f set 
field  SFVec3f  size 

1 

"CompassRosePrototype . x3d" 

Inline  { 

url  "CheckeredGround . x3d" 

} 

CompassRose  { 

locationOf f set  -0.075  -0.045  0 
size  111 

} 


Figure  29.  Example  Compass  Rose  X3D  Code  (VRML  Syntax) 


Figure  30.  X3D  Example  Compass  Rose  Scene  First  Looking  North,  then  Northwest 
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Port  Security  Barrier 

Planet  9  Studios  provided  a  copy  of  its  previously  existing  Port  Security  Barrier  (PSB) 
X3D  PROTO  of  the  for  release  into  the  open  source  FOUO  SavageDefense  archive,  thereby 
allowing  it  to  be  freely  used  and  modified  accordingly. 

This  X3D  PROTO  defines  a  single  section  of  a  Port  Security  Barrier.  A  complete  barrier 
system  is  created  by  stringing  several  PSB  sections  together  in  a  continuous  line.  In  most  cases, 
one  PSB  section  will  be  coupled  to  the  next  section  via  a  normal  hardware  connection.  However, 
in  cases  where  the  PSB  section  must  be  connected  to  a  special  float,  as  in  the  case  of  a  gate 
opening,  then  it  must  have  a  special  connector.  The  X3D  PROTO  allows  the  option  to  choose 
such  a  connector,  either  on  the  left  or  right  side  of  the  section,  via  the  attribute  “whichChoice”. 

Other  attributes  include  “translation”  and  “rotation”.  These  two  attributes  are  not 
truly  necessary,  of  course,  as  a  transform  could  just  as  easily  be  applied  to  the  X3D  node  from 
which  the  PROTO  is  called.  Note  that  each  PSB  section  is  15.3  meters  in  length,  and  so  this 
would  be  the  standard  translation  offset  when  there  is  a  straight  line  of  these  running  along  a 
primary  axis  (see  example  code  below). 

The  PSB  model  contains  four  levels  of  detail  (LODs).  The  highest  LOD  consists  of  2134 
polygons,  while  the  lowest  is  made  up  of  only  60  polygons.  Depending  on  the  number  of  PSB 
sections  included  in  a  given  scene,  the  “range”  field  of  the  X3D  “lod”  node  may  need  to  be 
adjusted  within  the  X3D  PROTO  code  to  enable  the  higher  LODs  to  switch  out  sooner.  In  this 
way,  the  overall  performance  may  be  increased. 


PortSecurityBarrierPrototype . x3d 

Attribute 

Default 

Option 

translation 

0  0  0 

XYZ  Modified  position  of  barrier  section 

rotation 

0  10  0 

Modified  rotation  of  barrier  section, 

in  vector  (XYZ)  and  rotation  (radians) 

whichChoice 

0 

0=Normal , 
l=LeftConnector , 

2 =Right Connect or 

Table  12.  Port  Security  Barrier  X3D  PROTO  attributes  and  options: 
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EXTERNPROTO  Barrier  [ 

exposedField  SFVec3f  translation 
exposedField  SFRotation  rotation 
exposedField  SFInt32  whichChoice 

] 

"PortSecurityBarrierPrototype . x3d" 


Barrier  { 

#  normal  barrier  section,  i.e.  it  only  connects  to  other  barriers. 

whichChoice  0 
translation  000 

} 

Barrier  { 

#  special  barrier  section  with  connection  hardware  on  its  left  side. 

whichChoice  1 
translation  -15.3  0  0 

} 

Barrier  { 

#  special  barrier  section  with  connection  hardware  on  its  right  side. 

whichChoice  2 
translation  15.3  0  0 


Figure  31.  Example  PSB  X3D  Code  (VRML  Syntax) 


Figure  32.  X3D  Example  PSB  Scene  First  with  One  Section,  then  Three  Sections. 
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X3D  Model  Locations 


Terrain: 

https://savagedefense.nps.navy.mil/SavageDefense/Locations/PearlHarborTerrain/index.html 

Buildings: 

https://savagedefense.nps.navv.mil/SavageDefense/Locations/PearlHarborBuildings/index.html 

Aids  to  Navigation: 

https://savage.nps.edu/Savage/HarborEquipment/NavigationAids/index.html 

Compass  Rose: 

https://savage.nps.edu/Savage/Tools/HeadsUpDisplays/index.html 

Port  Security  Barriers: 

https://savagedefense.nps.naw.mil/SavageDefense/HarborEquipment/FloatingBarriers/index.html 

Planet  9  Studios  AT/FP  Art  Team 

David  Colleen,  CEO 

Christian  Greuel,  Director  of  Art  &  Production 
Danny  Lee,  3D  Artist 
Carlos  Newcomb,  3D  Artist 
Ken  Rhee,  3D  Artist 
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GLOSSARY  OF  TERMS  AND  ACRONYMS 


2D 

3D 

ABOT 

ACTD 

API 

ARES 

ATD 

AT/FP 

ATON 

AUV 

AVERT 

BAA 

C2 

C4I 

CAC 

CAD 

CASS 

CAW 

C-BML 

CCRTS 

CEO 

CFFC 

CFO 


Two  Dimensional 

Three  Dimensional 

Al-Basrah  Oil  Terminal 

Advanced  Concept  Technology  Demonstration 

Application  Program  Interface 

Applied  Research  and  Engineering  Sciences 

Atmospheric  Transport  and  Dispersion 

Anti-Terrorism/Force  Protection 

Aids  to  Navigation 

Autonomous  Unmanned  Vehicle 

Automated  Vulnerability  Evaluation  for  Risks  of  Terrorism 
Broad  Agency  Announcement 
Command  and  Control 

Command,  Control,  Communications,  Computers,  and  Intelligence 

Common  Access  Card 

Computer  Aided  Design 

Comprehensive  Acoustic  Simulation  System 

Center  for  Asymmetric  Warfare 

Coalition  Battle  Management  Language 

Command  and  Control  Research  and  Technology  Symposium 

Chief  Executive  Officer 

Commander,  Fleet  Forces  Command 

Chief  Financial  Officer 
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CHDS 

Center  for  Homeland  Defense  and  Security 

CHRIS 

IHO  Committee  on  Hydrographic  Requirements  for  Information 

Systems 

CNI 

Commander,  Navy  Installations 

CNIC 

Commander,  Navy  Installations  Command 

CNO 

Chief  of  Naval  Operations 

CONOPS 

Concept  of  Operations 

CONUS 

Continental  United  States 

CVS 

Concurrent  Versioning  System 

DARPA 

Defense  Advanced  Research  Projects  Agency 

DARWARS 

DARPA-funded  program  for  achieving  training  superiority 

DEM 

Digital  Elevation  Model 

DES 

Discrete  Event  Simulation 

DHS 

Department  of  Homeland  Security 

DIS 

Distributed  Interactive  Simulation 

DMSO 

Defense  Modeling  and  Simulation  Office 

DNC 

Digital  Nautical  Chart 

DoD 

Department  of  Defense 

DOE 

Design  of  Experiments 

DTED 

Digital  Terrain  Elevation  Data 

EHSS 

Electronic  Harbor  Security  System 

EPiCS 

Emergency  Preparedness  Incident  Command  Simulation 

EO 

Electro-optical 

EOD 

Explosive  Ordnance  Disposal 
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ERDC 

Engineer  Research  and  Development  Center 

ESRI 

Environmental  Systems  Research  Institute 

FAQ 

Frequently  Asked  Questions 

FIRST 

Financial  Institution  Risk  Strategy  Tool 

FISC 

Fleet  Industrial  Supply  Center 

FOM 

Figure  of  Merit 

FOUO 

FOR  OFFICIAL  USE  ONLY 

GIG 

Global  Information  Grid 

GIS 

Geographic  Information  System 

GOPLATS 

Gas  and  Oil  Platforms 

GPS 

Global  Positioning  System 

GUI 

Graphical  User  Interface 

HiRSA 

High-Resolution  Situational  Awareness 

HLA 

High  Level  Architecture 

HPC 

High  Performance  Computing 

HUD 

Heads  up  Display 

HSDL 

Homeland  Security  Digital  Library 

IEEE 

Institute  for  Electronic  and  Electrical  Engineers 

IHO 

International  Hydrographic  Organization 

I/ITSEC 

Interservice/Industry  Training,  Simulation,  and  Education 

Conference 

Inc. 

Incorporated 

IR 

Infra-red 

IT/21 

Information  Technology  for  the  21st  Century 
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JCATS 

Joint  Conflict  and  Tactical  Simulation 

JMBL 

Joint  METOC  Broker  Language 

ICA 

Independent  Computing  Architecture 

ISO 

International  Standards  Organization 

LANDSAT 

Land  Remote-Sensing  Satellite 

LIDAR 

Light  Detection  and  Ranging 

LOD 

Level  of  Detail 

LT 

Lieutenant 

M&S 

Modeling  and  Simulation 

MCAS 

Marine  Corps  Air  Station 

METOC 

Meteorological  and  Oceanographic  Center 

MIL-STD 

Military  Standard 

MOE 

Measure  of  Effectiveness 

MOP 

Measure  of  Performance 

MOVES 

Modeling,  Virtual  Environments,  and  Simulation 

MSDL 

Military  Scenario  Definition  Language 

NAS 

Naval  Air  Station 

NASA 

National  Aeronautics  and  Space  Administration 

NATO 

North  Atlantic  Treaty  Organization 

NAVFAC 

Naval  Facilities  Command 

NAVMAG 

Naval  Magazine 

NAVSEA 

Naval  Sea  Systems  Command 

NAVSTA 

Naval  Station 

NFESC 

Naval  Facilities  Engineering  Service  Center 
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NMCI 

Navy-Marine  Corps  Internet 

NO  A  A 

National  Oceanic  and  Atmospheric  Administration 

NPS 

Naval  Postgraduate  School 

NSWC 

Naval  Surface  Weapons  Center 

NUWC 

Naval  Undersea  Warfare  Center 

OCONUS 

Outside  Continental  United  States 

ODE 

Open  Dynamics  Engine 

OPNAV 

Office  of  the  Chief  of  Naval  Operations 

ONR 

Office  of  Naval  Research 

OR 

Operations  Research 

PDA 

Personal  Digital  Assistant 

PDU 

Protocol  Data  Unit 

PEO 

Program  Executive  Office 

Ph.D. 

Doctor  of  Philosophy 

Pkill 

Probability  of  Kill 

PMS 

Program  Manager  Surface 

POA&M 

Plan  of  Actions  and  Milestones 

POC 

Point  of  Contact 

PSB 

Port  Security  Barrier 

R&D 

Research  and  Development 

RFID 

Radio  Frequency  Identification 

RHIB 

Rigid  Hull  Inflatable  Boat 

RSIMS 

Regional  Shore  Installation  Management  System 

RTI 

Run-Time  Infrastructure 
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S&ST 


SAIC 

SAVAGE 

SBIR 

SDTS 

SecForDMT 

SEDRIS 

SIPRNET 

SISO 

SIW 

SCORM 

SMAL 

SOP 

SOW 

SPAWAR 

SQL 

STRATA 

STRI 

SUBASE 

SWAT 

TENA 

TRAC 

TRADOC 


Sound  and  Sea  Technologies 

Science  Applications  International  Corporation 

Scenario  Authoring  and  Visualization  for  Advanced  Graphical 
Environments 

Small  Business  Innovative  Research 

Spatial  Data  Transfer  System 

Security  Forces  Distributed  Mission  Training 

Synthetic  Environment  Data  Representation  Interchange  Standard 

Secret  Internet  Protocol  Router  Network 

Simulation  Interoperability  Standards  Organization 

Simulation  Interoperability  Workshop 

Shareable  Content  Object  Reference  Model 

Savage  Modeling  and  Analysis  Language 

Standard  Operating  Procedures 

Statement  of  Work 

Space  and  Naval  Warfare  Command 

Standard  Query  Language 

Synthetic  Teammates  for  Realtime  Anywhere  Training  and 
Assessment 

Simulation,  Training,  and  Range  Instrumentation 

Submarine  Base 

Special  Weapons  and  Tactics 

Test  and  Training  Enabling  Architecture 

TRADOC  Analysis  Center 

Training  and  Doctrine  Command 
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UI 

User  Interface 

UML 

Unified  Modeling  Language 

UNO 

University  of  Nebraska,  Omaha 

URL 

Uniform  Resource  Locator 

USGS 

United  States  Geological  Survey 

USN 

United  States  Navy 

UTM 

Universal  Transverse  Mercator 

VC 

Visual  C++ 

V&V 

Verification  and  Validation 

VR 

Virtual  Reality 

VRML 

VR  Modeling  Language 

W&A 

Verification,  Validation,  and  Accreditation 

WEAVER 

Web-Enabled  Architecture  for  Visualization,  Evaluation  and 

Research 

WSMR 

White  Sands  Missile  Range 

WSS 

Waterside  Security 

X3D 

Extensible  3D  Graphics 

Xj3D 

Extensible  Java™  API  for  X3D 

XML 

Extensible  Markup  Language 

XMSF 

Extensible  Modeling  and  Simulation  Framework 

XSBC 

XML  Schema-based  Binary  Compression 

XTC 

XML-based  Tactical  Chat 

ZLIB 

An  Open  Source  Compression  Library 
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